|
DarkLotus posted:When a user is added or changes their email address and you create the new hash, make sure it doesn't exist, if it does create a new one until it is unique. How do I create a new hash until it is unique? The hash is based on a process, not randomness. LP0 ON FIRE fucked around with this message at 22:00 on Nov 3, 2015 |
#
?
Nov 3, 2015 21:57
|
|
|
|
| # ? May 16, 2024 16:10 |
|
|
LP0 ON FIRE posted:No wait. Hashing doesn't guarantee a unique value. I know the chances are extremely small, but it doesn't seem right to me. You are hashing the passwords already, and have a similar 'problem', which is not worth worrying about. DarkLotus posted:When a user is added or changes their email address and you create the new hash, make sure it doesn't exist, if it does create a new one until it is unique. Don't do this, you'll just be needlessly checking the database. A good cryptographic hash should have such a low chance of collision as to not be worth worrying about, especially for this use. Skandranon fucked around with this message at 22:00 on Nov 3, 2015 |
|
#
?
Nov 3, 2015 21:58
|
|
|
Skandranon posted:You are hashing the passwords already, and have a similar 'problem', which is not worth worrying about. Hashing passwords guaranteed that the user's row is unique by requiring that the username (email) is unique. Having two user passwords that have the same hash is virtually inconsequential.
|
|
#
?
Nov 3, 2015 22:02
|
|
|
LP0 ON FIRE posted:Hashing passwords guaranteed that the user's row is unique by requiring that the username (email) is unique. Having two user passwords that have the same hash is virtually inconsequential. If you are really worried about hash collisions, use a guid ID key instead of an auto-incrementing one.
|
|
#
?
Nov 3, 2015 22:04
|
|
|
Skandranon posted:How does encrypting the data help secure anything if the IV is also in the same database? Source: some dude on StackOverflow, though I don't do much with crypto so please feel free to correct me if I'm wrong. LP0 ON FIRE posted:Good point. These will be stored in a separate database when the site is live. Again, without the password the data should be useless. IVs are used to make sure the data, once encrypted, can't be easily compared with known encrypted strings. The crypto password is the thing you really need to be careful about. I'd recommend handling this like any other credential and inject it into your application as an environment variable. Even if someone snapshots your codebase and database they'll still be unable to resolve the encrypted data. About the only way they can then get those credentials is with direct access to your server, in which case you're completely hosed anyway. LP0 ON FIRE posted:No wait. Hashing doesn't guarantee a unique value. I know the chances are extremely small, but it doesn't seem right to me. As everyone has already said, the likelihood of two users email addresses hashing into the same string is extremely remote. It's conceivable that someone could engineer a collision, but I don't see how that would be beneficial to them. The limited space of email addresses (254 chars) with the average one being ~25 characters means it's really not going to be a problem. If it's a real deal breaker, consider using an SHA-2 function like SHA-512, instead. LP0 ON FIRE posted:Hashing passwords guaranteed that the user's row is unique by requiring that the username (email) is unique. Having two user passwords that have the same hash is virtually inconsequential. It is not inconsequential that two users may end up with the same hash. In fact, it should be drat near implausible for this to occur. Why? Because password salting. If two users use the same password "robbie", then they should still end up with two different hashes because you add a random salt to the password before it is hashed. You can't lookup a user by doing a simple SQL query of "where user=x and password=y" because the password salt should be unique per user, and you need to fetch that salt before you can calculate the password hash. Without these steps you can just use a rainbow table to reverse lookup peoples passwords. You don't use a static salt either (one for all users) because it's easy to generate a unique rainbow table for your system and lookup 30-50% of the most common passwords. Further more, you should be using something like bcrypt which has all this built in, including scalable computationally expensive methods which significantly slows down brute force cracking of those hashes. Again, I really hope you're doing all this already and I'm just misunderstanding why you said those things.
|
|
#
?
Nov 4, 2015 02:14
|
|
|
v1nce posted:This is a nice thought, but if you have a DB breach it probably won't matter. A dump is a dump is a dump. Chances are it'll contain everything and they'll still have all your IVs. This is what I was getting at, unless there is a lot of work going on that's not being discussed, encrypting as asked isn't going to be helping anything in the event of a real breach.
|
|
#
?
Nov 4, 2015 03:30
|
|
|
LP0 ON FIRE posted:Hashing passwords guaranteed that the user's row is unique by requiring that the username (email) is unique. Having two user passwords that have the same hash is virtually inconsequential. A solution to make the hash unique is just to include the auto-incremented ID in the hash. Take a look at how django does it. Either way, I guess I don't really see the point of trying to keep the emails hidden. Those are generally a pretty public thing, seem like it's just adding unnecessary complexity and overhead to your system.
|
|
#
?
Nov 4, 2015 04:12
|
|
|
Skandranon posted:This is what I was getting at, unless there is a lot of work going on that's not being discussed, encrypting as asked isn't going to be helping anything in the event of a real breach. Maybe I misunderstood you, but it originally sounded like you were saying putting the encryption IV in the database would contribute to a security risk for the encrypted data. To clarify, I don't think that statement is true because without the encryption password (key) the encrypted data and IV is useless to an attacker. They still have to brute-force the shared password. If you could somehow prevent an attacker from getting the IVs then all you're doing is introducing another level of complexity in brute forcing the decryption, by whatever the length of your IV is. You might as well just make your password that much longer and it'll have the same effect as making the attacker guess as 32-character IV. Encrypting as he stated, provided he keeps the password safe (not in code, not in db) then it should be completely OK. In the event that someone got a complete snapshot of the site (code and db) then providing the creds weren't in the code (use environment-variables damnit!), we know that an attacker has to spend quite a while brute forcing the password. EmptyFlash posted:A solution to make the hash unique is just to include the auto-incremented ID in the hash. Again, there's no reason to fear a hash collision in email addresses, and if it's that important to you then then you should just use one of the better SHA-2 algorithms where there are no known collisions. Also, I agree with you that hashing the email addresses is probably a pointless and painful exercise. In a data breach I think I'm least concerned about my email maybe getting a few more drops of spam.
|
|
#
?
Nov 4, 2015 04:52
|
|
|
I'm looking for an alternative to font icons (ie Bootstrap, FontAwesome). I have a website designed for internal use, partly on work computers, and partly on home computers or phones. I'm using font-awesome icons, which don't show up on work computers; I'm assuming due to font downloading' being disabled in IE security settings. What's the best way to handle this? Could I specificity an equivalent of alt text, and show a unicode character in place of the icon if it fails to load? An alt-image?
|
|
#
?
Nov 4, 2015 10:50
|
|
|
Dominoes posted:I'm looking for an alternative to font icons (ie Bootstrap, FontAwesome). I have a website designed for internal use, partly on work computers, and partly on home computers or phones. I'm using font-awesome icons, which don't show up on work computers; I'm assuming due to font downloading' being disabled in IE security settings. Can't fontawseome be included locally?
|
|
#
?
Nov 4, 2015 10:54
|
|
|
nexus6 posted:Can't fontawseome be included locally?
|
|
#
?
Nov 4, 2015 11:10
|
|
|
Some browsers have differences in the same origin policy, which restricts loading of content from other domains for security reasons. That might be what happened.
|
|
#
?
Nov 4, 2015 12:45
|
|
|
Dominoes posted:I'm looking for an alternative to font icons (ie Bootstrap, FontAwesome). I have a website designed for internal use, partly on work computers, and partly on home computers or phones. I'm using font-awesome icons, which don't show up on work computers; I'm assuming due to font downloading' being disabled in IE security settings. How many icons? Why not use SVGs? etc. I've seen client sites where they included two full typefaces for a grand total of three icons....
|
|
#
?
Nov 4, 2015 15:11
|
|
|
v1nce posted:In the event that someone got a complete snapshot of the site (code and db) then providing the creds weren't in the code (use environment-variables damnit!), we know that an attacker has to spend quite a while brute forcing the password. Is it actually all that common for attackers to get code+db dumps but not be able to read environment values from live machines or find setup scripts/chef configs/whatever? quote:Also, I agree with you that hashing the email addresses is probably a pointless and painful exercise. In a data breach I think I'm least concerned about my email maybe getting a few more drops of spam. If Ashley Madison had encrypted their DB values, a lot of people wouldn't be dealing with blackmail threats right now.
|
|
#
?
Nov 4, 2015 15:29
|
|
|
Munkeymon posted:Is it actually all that common for attackers to get code+db dumps but not be able to read environment values from live machines or find setup scripts/chef configs/whatever? Yes: not code dumps, but SQLi results in DB dumps, but NOT code dumps or reading envvars. But if you use a poo poo db that allows some form of SELECT EXEC(WHATEVER) then all bets are off AM has a whole other group of issues, and no this would not have helped in any way - AM appears to have been significantly compromised well past db considering even internal emails were leaked, and on top of that they weren't even close to following best practice considering no verification of emails, and hashing passwords with md5() Impotence fucked around with this message at 16:36 on Nov 4, 2015 |
|
#
?
Nov 4, 2015 16:34
|
|
|
Biowarfare posted:Yes: not code dumps, but SQLi results in DB dumps, but NOT code dumps or reading envvars. But if you use a poo poo db that allows some form of SELECT EXEC(WHATEVER) then all bets are off Right, I can't picture an access model that doesn't leak machine state that does leak code other than 'woops just made the repo public' but that could easily be my lack of pro-tier sysadmin experience. And yeah, I should have qualified the thing about AM quite a bit more, but if they had been encrypting their DB, it's likely that the rest of their security would have been a lot less lovely to match v  v
|
|
#
?
Nov 4, 2015 16:56
|
|
|
Weird question; anyone have inspiration for a design for a terminal with white background/lighter theme? Basically I'm going to be scrolling data like an actual terminal but it needs to look modern/professional versus the green screen hacker look. A screenshot would be fine, just looking for inspiration.
|
|
#
?
Nov 4, 2015 19:12
|
|
|
revmoo posted:Weird question; anyone have inspiration for a design for a terminal with white background/lighter theme? Basically I'm going to be scrolling data like an actual terminal but it needs to look modern/professional versus the green screen hacker look. A screenshot would be fine, just looking for inspiration. I love me some http://ethanschoonover.com/solarized
|
|
#
?
Nov 4, 2015 19:23
|
|
|
v1nce posted:It is not inconsequential that two users may end up with the same hash. In fact, it should be drat near implausible for this to occur. Why? Because password salting. If two users use the same password "robbie", then they should still end up with two different hashes because you add a random salt to the password before it is hashed. Thanks for the info! Yup, I use salts, and when comparing passwords to the encrypted version, I use slow equals to resist timing attacks. v1nce posted:Also, I agree with you that hashing the email addresses is probably a pointless and painful exercise. In a data breach I think I'm least concerned about my email maybe getting a few more drops of spam. Any security breach that publicly publishes data that is easily read by humans ruins the developers credibility. Munkeymon posted:Is it actually all that common for attackers to get code+db dumps but not be able to read environment values from live machines or find setup scripts/chef configs/whatever? Sure. You shouldn't store the keys/secret pass codes on the database to decrypt the information. Instead, use a separate machine, like a key vault.
|
|
#
?
Nov 4, 2015 21:16
|
|
|
fuf posted:I love me some http://ethanschoonover.com/solarized That's a good one, I also like https://studiostyl.es/schemes/monokai
|
|
#
?
Nov 4, 2015 21:55
|
|
|
Not really looking for code oriented syntax highlighting, neither of those are clean enough examples to use. So far I've just got a monospaced font and some inset box shadow and that's looking pretty good. I think I'm just going to stick with that.
|
|
#
?
Nov 4, 2015 22:05
|
|
|
revmoo posted:Not really looking for code oriented syntax highlighting, neither of those are clean enough examples to use. It's probably not what you want, but I started this a couple of years ago before I got distracted: http://samglover.net/terminal Here's the code, if you dig it: https://github.com/samglover/terminal If you changed up the colors it might save you some time, I dunno.
|
|
#
?
Nov 4, 2015 22:14
|
|
|
Nah, I guess I should explain what I'm doing. I'm streaming log data from firewalls thru an hdfs cluster to a message queue that lets me grab the live firehose and filter it, and I'm displaying the raw log data in the browser using websockets. So users will see a scrolling list of logging data. The site is very lightly-colored in its default state so I want something that is clean, light, and professional. I want some semblance of a 'terminal' look but with a bit more cleanliness. e: I just need a little more "pop" okay
|
|
#
?
Nov 4, 2015 22:19
|
|
|
LP0 ON FIRE posted:Sure. You shouldn't store the keys/secret pass codes on the database to decrypt the information. Instead, use a separate machine, like a key vault. OK great so what's preventing an attacker from making what looks like a perfectly normal key request from an owned machine? In this scenario, the attacker can see the code that makes the requests, so it should be trivial to replicate one. Or are we assuming they got the code with, say read-only-no-execute access?
|
|
#
?
Nov 4, 2015 22:31
|
|
|
revmoo posted:Nah, I guess I should explain what I'm doing. I'm streaming log data from firewalls thru an hdfs cluster to a message queue that lets me grab the live firehose and filter it, and I'm displaying the raw log data in the browser using websockets. So users will see a scrolling list of logging data. The site is very lightly-colored in its default state so I want something that is clean, light, and professional. I want some semblance of a 'terminal' look but with a bit more cleanliness. Why in the world aren't you using an ELK stack?
|
|
#
?
Nov 4, 2015 23:08
|
|
|
LP0 ON FIRE posted:Thanks for the info! Yup, I use salts, and when comparing passwords to the encrypted version, I use slow equals to resist timing attacks. You never roll your own when it comes to crypto and hashing. You shouldn't need to know terms like "slow equals" to safely hash a password using an existing algorithm/library. LP0 ON FIRE posted:Any security breach that publicly publishes data that is easily read by humans ruins the developers credibility. Munkeymon posted:Is it actually all that common for attackers to get code+db dumps but not be able to read environment values from live machines or find setup scripts/chef configs/whatever? Security is all about preventative measures and mitigating risk. You apply security by recognising the potential attack vectors and then plugging the holes, or taking steps to reduce risk as best you can. You can't just throw security measures blindly at a problem and go "There, nobody's getting through that!" because security is only as strong as the weakest link in the chain. If you haven't properly analysed all your potential attack vectors then you've probably left a side door wide open without realising. If you can't afford to pay a security consultant to do this for you (hint: nobody can), then one of the best ways to approach this to play war games between your most knowledgeable people and come up with preventative measures. We already play this game daily in our heads when we go "I don't want to be responsible for a password leak. Let's hash the passwords" and then again when you go "but if those hashes get leaked I want to give the hacker a hard time trying to figure out what they are. Let's not use MD5, lets use PBKDF2". Here, lets play a quick round of hypothetical gently caress ups: So what happens if your DB gets dumped into the wild? Well, we hash our passwords using an expensive algorithm so that's OK. But we're supposed to be confidential about membership, so let's make sure the identifying fields are encrypted, too. What happens if the DB and the code gets dumped into the wild? Well, our code has configs values in it, including our encryption keys. Let's mitigate the risk by moving the encryption keys to environment variables on the server, and not putting them anywhere else, and delete them from the VCS. What if someone gets access to our deploy scripts? Well, let's move the creds out of the scripts and VCS and put them as environment variables on our desktop, or just as a separate not-in-vcs script we can run to put them in place on our desktops before we run deployment scripts. What happens if someone gets access to the server? We're boned. If someone gets code-executable access to our server then they can look at everything, decrypt, export, there's literally no stopping them. How can we mitigate this risk of that happening? Let's make sure we're not using poo poo like eval() in our code, so arbitrary code execution isn't an easily available vector. Let's make our server structure immutable so we don't need shell access and can just run without it. Let's set up a honeypot so we can capture and identify potentially malicious users and connections, and black list them. What if someone gets access to out hosting? Again, there's very little chance this won't end in disaster, so what can we do? Most people who need access to our hosting won't need full gently caress up my life access, so let's give everybody reduced privileges which they can use to connect with daily. Let's make an admin account which we only use in case of emergency, or if we're going to do infrastructure changes. Only a few people have this access. Let's have a plan of action of who to call (AWS?) if we realise our creds are breached so the account can be locked down hard. Do we need a big red button we can press that destroys the internet connection to our server if we suddenly realise we're compromised? Probably not, unless we're the CIA. What if someone breaks into the office and steals my computer? While not usually the cause of a data breach, this is the most likely thing to ever happen to you. If the data on your machine is that sensitive (like, you're the guy with the keys to the castle) then perhaps you should use a password manager to securely store your poo poo, or even something like a TrueCrypt disk which you have to manually mount with every boot. Remember, this is an exercise in company-wide security. All the server security measures in the world won't help if your CEO demands to have access to the server password but is also easily socially engineered into giving them up to "Oh hey this is Brad McHaqer from AWS and we need to update your analytics". v1nce fucked around with this message at 00:50 on Nov 5, 2015 |
|
#
?
Nov 5, 2015 00:35
|
|
|
Honestly I don't think your plan of "store keying material on developer's workstations, but not under any form of version control" is a particularly good one, both from a security and from a business continuity standpoint.
|
|
#
?
Nov 5, 2015 01:15
|
|
|
I hear your opinion, but can you tell me why you think that is? Personally I feel creds should be stored in some kind of password manager, and ideally an API can fetch them out for use in scripts. They should never be stored in VCS or anything that might make its way onto the internet. The password manager aspect (if managed right) should mean the business has continuity in case I step out in front of a bus.
|
|
#
?
Nov 5, 2015 01:23
|
|
|
You're basically hosed if your office has a fire, major flood, or even just hardware failure that wrecks your developer machine to the point where you can't pull your key material from it. In addition to that, you have no ability to audit accesses to that material, so an attacker that gains access (or even just a rogue employee) can easily exfiltrate it without tripping any red flags. A better solution is to use hardware-backed security so that you don't have raw keying material anywhere that a human could possibly read it - for business continuity and standing up new servers you have copies in (geographically distributed) physical safes with strictly controlled and logged physical access.
|
|
#
?
Nov 5, 2015 02:12
|
|
|
Jabor posted:Honestly I don't think your plan of "store keying material on developer's workstations, but not under any form of version control" is a particularly good one, both from a security and from a business continuity standpoint. Vault basically exists for that reason
|
|
#
?
Nov 5, 2015 02:17
|
|
|
Blinkz0rz posted:Why in the world aren't you using an ELK stack? I'm not the person to say. What I can say is that we've been through a number of platforms and iirc we looked at that. Right now Impala/storm is the flavor of the day, the latter of which is allowing us to stream data over websockets. Which btw is INSANE. Websockets can push some serious data, fast. I'm really psyched about the tech. It's way more sophisticated than Ajax or even Comet.
|
|
#
?
Nov 5, 2015 02:23
|
|
|
This is exactly something I want to look into, and thanks for explaining. Due to paranoia our business only had two keyholders for some critical infrastructure and it's something I really need to find a way to fix.Blinkz0rz posted:Vault basically exists for that reason
|
|
#
?
Nov 5, 2015 02:43
|
|
|
revmoo posted:Nah, I guess I should explain what I'm doing. I'm streaming log data from firewalls thru an hdfs cluster to a message queue that lets me grab the live firehose and filter it, and I'm displaying the raw log data in the browser using websockets. So users will see a scrolling list of logging data. The site is very lightly-colored in its default state so I want something that is clean, light, and professional. I want some semblance of a 'terminal' look but with a bit more cleanliness. I think Papertrail looks pretty nice for that type of thing. Maybe too dark? I can't seem to find an image of their different colors you get if you click "Contrast" 
EmptyFlash fucked around with this message at 03:23 on Nov 5, 2015 |
|
#
?
Nov 5, 2015 03:18
|
|
|
v1nce posted:What happens if someone gets access to the server? What happens if an attacker convinces your hosting company (assuming not AWS) to hook up IPMI/OOB-KVM, reboot into single user mode? Are disks encrypted at rest too?
|
|
#
?
Nov 5, 2015 04:12
|
|
|
Biowarfare posted:What happens if an attacker convinces your hosting company (assuming not AWS) to hook up IPMI/OOB-KVM, reboot into single user mode? Are disks encrypted at rest too?
|
|
#
?
Nov 5, 2015 04:38
|
|
|
v1nce posted:Questions like this are why you need to play the game with knowledgeable people. Half the time I get to play this game with freelance or contract clients it results in "why can't we just use godaddy shared hosting"
|
|
#
?
Nov 5, 2015 04:41
|
|
|
Is there a HTML5 replacement for the below code, or a better way o enable momentum scrolling on iPads? Apparently iOS 9 doesn't like it and the page crashes on just this.code:kloa fucked around with this message at 16:14 on Nov 5, 2015 |
|
#
?
Nov 5, 2015 16:07
|
|
|
Munkeymon posted:OK great so what's preventing an attacker from making what looks like a perfectly normal key request from an owned machine? In this scenario, the attacker can see the code that makes the requests, so it should be trivial to replicate one. Or are we assuming they got the code with, say read-only-no-execute access? One scenario may be that you setup the vault so it only interacts with the server it's setup on. You can configure access control polices much like you said. I'm still learning about this myself, and it has lots of pieces that makes it all work, but you can check out the docs for Vault Project and Azure Vault which looks to be more capable and robust, but not free like Vault.
|
|
#
?
Nov 5, 2015 17:03
|
|
|
Munkeymon posted:OK great so what's preventing an attacker from making what looks like a perfectly normal key request from an owned machine? In this scenario, the attacker can see the code that makes the requests, so it should be trivial to replicate one. Or are we assuming they got the code with, say read-only-no-execute access? If they see the code, they still need to be able to execute the request from within your internal network. Secret managements basically result in a ton of pros: every single key request being logged and auditable [and possibly rejectable if they look suspicious, happen at a time that don't coincide with reboots or restarts of your machines, be at a higher volume than normal], immediate invalidation and cycling of keys throughout the entire infrastructure or disabling the ability of an owned machine to acquire any secrets at all, passwords not being present in envvars, config files, or otherwise, using a secrets-server allowing automated management of AWS KMS and IAM.
|
|
#
?
Nov 5, 2015 17:51
|
|
|
|
| # ? May 16, 2024 16:10 |
|
|
Biowarfare posted:If they see the code, they still need to be able to execute the request from within your internal network. Which is what I meant by "an owned machine" - should have clarified because I'm thinking about what happened to Target. quote:Secret managements basically result in a ton of pros: every single key request being logged and auditable [and possibly rejectable if they look suspicious, happen at a time that don't coincide with reboots or restarts of your machines, be at a higher volume than normal], immediate invalidation and cycling of keys throughout the entire infrastructure or disabling the ability of an owned machine to acquire any secrets at all, passwords not being present in envvars, config files, or otherwise, using a secrets-server allowing automated management of AWS KMS and IAM. Now that's what I'm talking about. I wouldn't have thought to check for suspicious reboots or for key requests that don't correspond to a reboot, for example.
|
|
#
?
Nov 5, 2015 18:12
|
|