|
Jonny 290 posted:I know every user's password in one particular system here is most likely the day of the week they called in for their last password reset, with "1!" appended. Speaking of resets, I left my SA password as the one they sent me in an email for about 8 or 12 months because I only signed in on new computers and it was easy enough to just copy/paste it out of my email. The moral being either force a password change on login or make sure your autogenerated ones are strong (SA sends out GUIDs or strings resembling them).
|
#
?
Mar 1, 2013 22:53
|
|
|
|
| # ? May 17, 2024 18:29 |
|
|
Speaking of poo poo password practices... This is the password I have entered on the site. 
|
|
#
?
Mar 2, 2013 01:12
|
|
|
door.jar posted:Man, I long for the day where plain text passwords in a DB is the worst horror I encounter. Not a bad plan, perhaps, but they balked when this led to them getting taken to a login page with the username pre-filled and prompting for the password. Turns out they expected those REST calls (which dealt purely with simple census data points that both sides shared) to completely bypass the login to our site, not just be a convenient token that cuts down on customer service calls of people forgetting their username. We had to explain more than a couple times that this would amount to us giving them a tool to view the medical data of individuals which is so hilariously verboten that we'd be destroyed in an audit, and out of business when company X's next round of layoffs targeted individuals whose glucose levels on their last blood draw indicated pre-diabetic conditions. Makes me wonder about the number of cross-platform agreements that go over without a consideration for these sorts of details. And then I remember my job circa 2004 with a networking hardware manufacturer, who was partnered with SBC, who was partnered with Yahoo!, who offered yahoo email for every SBC subscriber, who created an admin tool that allowed you to ghost into the full yahoo email client of any SBC subscriber, who then bundled that tool into a suite of other tools, which they shared with some of their partners including us the hardware manufacturer. Ostensibly so we could help with support problems via some of the other tools, but not only did we have full access to the suite of tools including email ghosting, we were also given training on it. If you're developing the software and shipping it that's one thing as far as security is concerned. But for my money the world of operations, devops, and corporate partnering exposes the human element of security flaws, which can put plaintext password columns to shame. Bhaal fucked around with this message at 01:24 on Mar 2, 2013 |
|
#
?
Mar 2, 2013 01:20
|
|
|
shrughes posted:The same reason that using a per-user random salt (with a fast hash function) is a bad thing. I'm not saying to use a fast hash. Something like this: php:<? bcrypt(username . short_system_salt . password, full_system_salt); ?> * provide plenty of entropy * ensure that two users who use the same password don't visibly appear to have the same one based on the hash
|
|
#
?
Mar 2, 2013 01:38
|
|
|
bobthecheese posted:I'm not saying to use a fast hash. Something like this: I'm going to murder your family
|
|
#
?
Mar 2, 2013 01:46
|
|
|
Bunny Cuddlin posted:I'm going to murder your family Hey look, please explain to me why this is less secure than bcrypt(password, salt);. I know that I know gently caress all about crypto, but if you can explain why this is more vulnerable, then please do so.
|
|
#
?
Mar 2, 2013 02:00
|
|
|
Ithaqua posted:[edit] Also, it's usually a sign of a really bad culture of people who have a "if it's Not Invented Here, it's no good!" attitude, and are constantly reinventing the wheel. Worse than NIH is "Oh, There's No Free and Open Source Library That Does This? Can't Have That Feature." I get really annoyed at work when the other programmers don't wanna get the owner to spring for a library or tool to do something complicated(exporting to Excel 2003, generating PDFs. FML).
|
|
#
?
Mar 2, 2013 02:05
|
|
|
bobthecheese posted:Hey look, please explain to me why this is less secure than bcrypt(password, salt);. I know that I know gently caress all about crypto, but if you can explain why this is more vulnerable, then please do so. If you're genuinely curious, maybe give this a read? I'm feeling that you ignored the last few pages discussing salts and understanding/following standard practices, so this might be too much to ask. Edit add: Your inclusion of the username in the salt is the only thing ensuring that the salt is at all different across users. The "system-wide" component is useless, and you're better off just using a random string for the entire salt anyway, rather than limiting it to strings that people use for usernames. As a bonus, you can support username changes without also requiring a password reset when said changes occur. Progressive JPEG fucked around with this message at 02:19 on Mar 2, 2013 |
|
#
?
Mar 2, 2013 02:12
|
|
|
Progressive JPEG posted:As a bonus, you can support username changes without also requiring a password reset when said changes occur. Don't take this as me arguing against you, or heaven forbid for bobthecheese, but the idea that username changes not requiring a password reset is flawed. Any and all user actions should have a secondary gate of requiring a valid password, even if they're logged in. This results in one checking the user's old password, hashing the new password with the new username, and then saving the new username and password, if they were to do something stupid like use a username as a portion of the salt. But at the end of the day, hashing a password with the username is such a minor security boost, it's useless. If you're going through the trouble of having unique per-user salts, generate a good salt. Don't toss whatever poo poo you have lying around into it and think that an attacker won't notice. You can guarantee a computationally expensive task, you can't guarantee the ingenuity of the person sitting there with a dump of your DB.
|
|
#
?
Mar 2, 2013 02:29
|
|
|
UxP posted:Don't take this as me arguing against you, or heaven forbid for bobthecheese, but the idea that username changes not requiring a password reset is flawed. Any and all user actions should have a secondary gate of requiring a valid password, even if they're logged in. This results in one checking the user's old password, hashing the new password with the new username, and then saving the new username and password, if they were to do something stupid like use a username as a portion of the salt. You're assuming that the only way for a username to change is for users to change it themselves. If an administrator needs to change it, there's no way to do it without invalidating the password.
|
|
#
?
Mar 2, 2013 02:34
|
|
|
UxP posted:Don't take this as me arguing against you, or heaven forbid for bobthecheese, but the idea that username changes not requiring a password reset is flawed. Any and all user actions should have a secondary gate of requiring a valid password, even if they're logged in. This results in one checking the user's old password, hashing the new password with the new username, and then saving the new username and password, if they were to do something stupid like use a username as a portion of the salt. It's absolutely 0 security boost and you've introduced some ridiculous horseshit that needlessly complicates both changing names and the login process.
|
|
#
?
Mar 2, 2013 02:43
|
|
|
Bhaal posted:Kind of a tangent, but I work in healthcare inside the US (that is, we hold personal identity and health info so we have to be HIPAA complaint). We recently had to fight back on a "universal sign on" initiative with a large client of ours who have tens of thousands of individuals in our system. As a user convenience/experience improvement, they wanted their employees to be able to sign in on THEIR site and then have a link that would portal them straight into our site. We agreed on a spec for some REST calls that used name, DOB, etc. to create a link between the two identity databases so that the user could get in more easily. What the gently caress why wouldn't you just use ADFS or SAML to trust/verify, and then transmit the info? e: not a personally directed question, just that my mind exploded...
|
|
#
?
Mar 2, 2013 03:05
|
|
|
trex eaterofcadrs posted:What the gently caress why wouldn't you just use ADFS or SAML to trust/verify, and then transmit the info? I'm guessing that brings the AD forest or at least the entire other application into the scope of whatever security constraints he's working under.
|
|
#
?
Mar 2, 2013 03:16
|
|
|
Progressive JPEG posted:I don't see why you're so intent on avoiding the standard practice of having a cryptographically random per-user string as the salt. Doing this would allow you to skip your completely pointless "system-wide" salts entirely. If you're LinkedIn and your DB just got dumped, someone's going to be trivially including those "system-wide" salts when brute forcing your hashes. Don't you also have a static salt or something stored outside of the database in some kind of protected config file as a second salt in the event of a database but not filesystem compromise?
|
|
#
?
Mar 2, 2013 03:25
|
|
|
bobthecheese posted:* provide plenty of entropy
|
|
#
?
Mar 2, 2013 03:26
|
|
|
Biowarfare posted:Don't you also have a static salt or something stored outside of the database in some kind of protected config file as a second salt in the event of a database but not filesystem compromise? And really I can't think of a lot of situations where you screwed up to the point that someone's gotten your DB but not so much that they also got some sort of read access to that system-wide salt. Everything that needs to verify a password will need access to that salt, so it'll presumably be all over the place anyway.
|
|
#
?
Mar 2, 2013 03:32
|
|
|
And to think of it another way, if all that's keeping someone from getting closer to recovering a LinkedIn-sized goldmine is a single system-wide value, it'll be a trivial amount of time for them to get it.
|
|
#
?
Mar 2, 2013 03:52
|
|
|
Progressive JPEG posted:I don't see why you're so intent on avoiding the standard practice of having a cryptographically random per-user string as the salt. Doing this would allow you to skip your completely pointless "system-wide" salts entirely. If you're LinkedIn and your DB just got dumped, someone's going to be trivially including those "system-wide" salts when brute forcing your hashes. Thanks, that explained it to me, and has shown me why a per-user random salt is worthwhile. I was just trying to avoid another field in the schema when there are existing ones that I thought would do the job. My main thinking (and I'll admit that it's a poor line of thought) was that bcrypt/scrypt/whatever is meant to be the part that makes brute-forcing difficult, not having a random salt-per-username, so by using an existing piece of data I could ensure that at least the hashes look different, so that finding out one password doesn't leave other users with the same password as vulnerable. And I suppose you're right - what's one more piece of data in the database? See? Learning is happening.
|
|
#
?
Mar 2, 2013 04:57
|
|
|
As a rule, if there's a library performing a cryptographic function, then it's designed to be used in the most straightforward way possible. Any of the configuration options are really there more to give developers knobs they can feel smart for understanding the labels on than actually turning them. It uses PBKDF2 by default? Fine by me. I might be tempted to pick a higher number of iterations but there's no algorithm that's going to save anybody who picks a password off this list if an attacker's willing to spend the time just trying those with every user account. Yeah, they don't get some infinitesimal percentage of the passwords but even half of them is a pretty good haul for a major website. If it's important that nobody sees a user's password when transmitting it to the site, then use TLS. Hell, use TLS anyhow and if it becomes a performance issue nobody will dare suggest disabling it over buying the necessary hardware. If TLS isn't enough to ensure that someone's password is secure on the wire, then use certificates. If it's a business application then use SSO and save everyone the trouble. Anybody who even thinks of using Javascript-based cryptography is a complete loving imbecile. Even if you get hacked, remember that you did the best that anybody could expect by not second-guessing the experts. Time spent doing that could be far more productively used ensuring that everything security related in the application is as simple as humanly possible and that there's a clear delineation between trusted and untrusted data.
|
|
#
?
Mar 2, 2013 06:37
|
|
|
Bhaal posted:and out of business when company X's next round of layoffs targeted individuals whose glucose levels on their last blood draw indicated pre-diabetic conditions. It took me a while to work out why this would ever happen, and then I remembered that the biggest horror in this thread continues to be America's healthcare system.
|
|
#
?
Mar 2, 2013 13:27
|
|
|
armorer posted:If I sign up for a system and it sends me an email containing my password, I change my password to something ungodly complex and never use that service again unless I have no other choice. I have to point out that just because someone emails your password doesn't mean they are storing it in plain text.
|
|
#
?
Mar 3, 2013 04:15
|
|
|
Murodese posted:It took me a while to work out why this would ever happen, and then I remembered that the biggest horror in this thread continues to be America's healthcare system. Hard NOP Life posted:I have to point out that just because someone emails your password doesn't mean they are storing it in plain text. I don't know about Murodese but Hard NOP can go back and find his original SA sign up email and find his original password. They weren't storing it in the clear though even back then.
|
|
#
?
Mar 3, 2013 04:20
|
|
|
Hard NOP Life posted:I have to point out that just because someone emails your password doesn't mean they are storing it in plain text. e: I guess you were applying it to the "sending an email when you sign up with your password in it" situation, which I guess is better.
|
|
#
?
Mar 3, 2013 04:21
|
|
|
The Gripper posted:Is that really that much of a distinction, though? If the password is stored in a reversible state then an attacker can reverse it as trivially as the password recovery system can. Am I right in thinking that if you have a reversible hash that can be output in plain text, then there must be either a universal key, or a key using non encrypted strings or something that is used to reverse that hash. That way when an attacker pulls the password list, they just need to figure out the magic passphrase and then away we go, they've got a strategy to decode the entire list in no time at all. As opposed to having to solve each individual password one by one with non reversible hashes. Have I got that right?
|
|
#
?
Mar 3, 2013 04:27
|
|
|
e;f,b
|
|
#
?
Mar 3, 2013 04:32
|
|
|
If a server side process decides to change a password and email you the current one, at no point was it stored in an irreversible way either.
|
|
#
?
Mar 3, 2013 04:37
|
|
|
Maluco Marinero posted:Am I right in thinking that if you have a reversible hash that can be output in plain text, then there must be either a universal key, or a key using non encrypted strings or something that is used to reverse that hash. That way when an attacker pulls the password list, they just need to figure out the magic passphrase and then away we go, they've got a strategy to decode the entire list in no time at all. As opposed to having to solve each individual password one by one with non reversible hashes. Non-reversible hashes need the attacker to generate a huge list of possible passwords and hashes to test against, and if the salt is different for each user (it should be) then an attack on one password has no bearing on any other password in the system, even if they are the same.
|
|
#
?
Mar 3, 2013 04:37
|
|
|
Not to mention the whole "don't put anything in an email that you wouldn't write on a postcard" angle.
|
|
#
?
Mar 3, 2013 04:39
|
|
|
Progressive JPEG posted:Not to mention the whole "don't put anything in an email that you wouldn't write on a postcard" angle. id rather have my password mailed to me on a postcard than sent to me in an email. the effort required to find and look at a postcard on its way to me is waaaaay higher than the effort required to eavesdrop on my email.
|
|
#
?
Mar 3, 2013 05:15
|
|
|
Hard NOP Life posted:I have to point out that just because someone emails your password doesn't mean they are storing it in plain text. This is true - you are 100% correct. I lean on the side of caution and assume they are storing it in plaintext, but they may not be. I should probably change it after that and see if they send it to me again, or if they send it to me when I go through the "forgot password" workflow before I get so annoyed with them.
|
|
#
?
Mar 3, 2013 16:41
|
|
|
Hard NOP Life posted:I have to point out that just because someone emails your password doesn't mean they are storing it in plain text.
|
|
#
?
Mar 3, 2013 17:43
|
|
|
Progressive JPEG posted:And really I can't think of a lot of situations where you screwed up to the point that someone's gotten your DB but not so much that they also got some sort of read access to that system-wide salt. Everything that needs to verify a password will need access to that salt, so it'll presumably be all over the place anyway.
|
|
#
?
Mar 4, 2013 09:27
|
|
|
It's a giant horror to store passwords in plain text, but it's an even bigger horror to use not-unique passwords and expect any level of security!
|
|
#
?
Mar 4, 2013 14:25
|
|
|
Is there no cryptography/secularity thread or something?
|
|
#
?
Mar 4, 2013 14:46
|
|
|
nexus6 posted:Is there no cryptography/secularity thread or something? I think D&D has a secularity thread somewhere, but I'm not seeing a crypto/security thread anywhere.
|
|
#
?
Mar 4, 2013 17:19
|
|
|
darthbob88 posted:I think D&D has a secularity thread somewhere, but I'm not seeing a crypto/security thread anywhere.
|
|
#
?
Mar 4, 2013 17:21
|
|
|
ninjeff posted:Crypto/secularity megathread: Taking the superstition out of security Counterpoint: http://www.schneier.com/blog/archives/2013/02/hacking_the_pap.html
|
|
#
?
Mar 4, 2013 17:24
|
|
|
nexus6 posted:Is there no cryptography/secularity thread or something? There's the Security Fuckup Megathread in YOSPOS...
|
|
#
?
Mar 4, 2013 20:34
|
|
|
trex eaterofcadrs posted:What the gently caress why wouldn't you just use ADFS or SAML to trust/verify, and then transmit the info? Not that I agree with it because this so regularly turns into a feedback loop with a company where you start to saddle IT with extra costs like the above, which makes IT into a larger cost center which makes you (the CEO and VPs and whoever) think of it as a monstrous cost center, which usually makes them gun shy when it comes to proposals aimed at eliminating technical debts and band-aid processes that have become integral to their operations. Instead they'll first look to cut corners with them and go for "cheaper" solutions (which usually translates to "more technical debt" but you usually can't quantify that case to them until said quantity is already out of control) and from then on it's an uphill battle just to keep your time-productivity efficiency from slipping further. That got a little hyperbolic (though I've seen some institutions that have fallen far down that hole), but back to the original point sometimes a technical argument can only goes so far when the stakes it raises are pennies compared to the bigger picture. Bhaal fucked around with this message at 21:32 on Mar 4, 2013 |
|
#
?
Mar 4, 2013 21:29
|
|
|
|
| # ? May 17, 2024 18:29 |
|
|
ExcessBLarg! posted:Furthermore, only one user needs a weak password for you to get in. With per-password salts you don't necessarily know which passwords are weak, so you either have to guess which users might have weak passwords, or otherwise iterate through the entire list of users, wasting time on the stronger ones. I hate to resurrect password chat, but I don't understand this line. Is the idea that your cracker will find derpPassword1 derpPrettyPrincess etc and you can figure out that "derp" is the salt pretty quickly, letting you power through the rest?
|
|
#
?
Mar 5, 2013 01:05
|
|
