|
shrughes posted:What? Keep the salt and the hash separate from the other user data, e.g., the username isn't part of the salt.
|
#
?
Mar 1, 2013 06:23
|
|
|
|
| # ? May 17, 2024 16:31 |
|
|
Related horror, our passwords aren't plaintext but still not the best. We use a timestamp column (specifically when the user was created) to salt the password When cleaning up the database schema, I discovered that this timestamp wasn't actually a timestamp, it was a string in ISO8601 format w/ microseconds (this is important) "OK I will just convert this to timestamp but during times where it needs to be used for the password we will just convert it into the ISO8601 format" *Converts column to TIMESTAMP (on local copy obviously)* *Realizes the TIMESTAMP column does not have support for milliseconds* *Looks up MySQL documentation* *Finds out only in the latest version of MySQL (5.6) supports milliseconds* "OK I guess we will just have to upgrade" *Finds out Amazon does not support MySQL 5.6* **Breaks down and cries** So everyone who says to just "use the username as the salt," gently caress YOU AND YOUR STUPID IDEA.
|
|
#
?
Mar 1, 2013 07:03
|
|
|
Man, I long for the day where plain text passwords in a DB is the worst horror I encounter. I just came across an application made by some other vendor where the web applications database connection details (including password of course) is stored in plaintext in every client's registry. So every installed client has everything they need for read/write access to the entire application DB which of course includes application wide settings, private records and basically everything you need to cause one of those big headline stories about hackers. Did I mention that I work in healthcare (outside the US)?
|
|
#
?
Mar 1, 2013 07:16
|
|
|
This isn't a coding horror yet, but... I'm starting work in two weeks time, my first real job, as an analyst programmer. I'm going to be maintaining a single app and addressing issues various clients have with it. It's a decently large team, which I'm thankful for, because it took me until my second interview to ask the question: "So what languages and tools might I be working with?" "Well, we have our own inhouse kind of language... it's kind of our own flavour of BASIC... We know it's not the most popular language out there, you'll have training." So, uh, how much trouble am I in?
|
|
#
?
Mar 1, 2013 07:18
|
|
|
door.jar posted:Did I mention that I work in healthcare (outside the US)? bewilderment posted:This isn't a coding horror yet, but... Are you working for Fog Creek Software?
|
|
#
?
Mar 1, 2013 07:30
|
|
|
Strong Sauce posted:It's either this, or the government. I am not. Is this something they do?
|
|
#
?
Mar 1, 2013 07:35
|
|
|
bewilderment posted:I am not. Is this something they do? Yes, or at least use to do. http://www.codinghorror.com/blog/2006/09/has-joel-spolsky-jumped-the-shark.html This seems expected since Spolsky was the PM for Excel and basically implemented Excel Basic/VBA. Funny given how Jeff Atwood later teamed up with Joel to do StackExchange.
|
|
#
?
Mar 1, 2013 07:46
|
|
|
They don't do that anymore. They had a legacy codebase in ASP/VBScript, and customers wanted it on other platforms, so rather than port the software (to what?), they ported the platform. It's a pragmatic solution, if ugly and slightly embarrassing. Nowadays, FogBugz is mostly written in C#/ASP.NET, and they've contributed patches to Mono and such to make sure it runs better on all servers. Their Wasabi stuff is still there, but it's getting slimmer by the day as they fix bugs and add features. New projects and new code aren't written in Wasabi.
|
|
#
?
Mar 1, 2013 08:48
|
|
|
Strong Sauce posted:Yes, or at least use to do. http://www.codinghorror.com/blog/2006/09/has-joel-spolsky-jumped-the-shark.html Joel Spolsky's most egregious horror is having lent a measure of legitimacy to Jeff Atwood.
|
|
#
?
Mar 1, 2013 08:49
|
|
|
bewilderment posted:"Well, we have our own inhouse kind of language... it's kind of our own flavour of BASIC... We know it's not the most popular language out there, you'll have training." A lot. Writing a good programming language is really hard. They might have a few super-genius compiler engineers working there that have created a really awesome language. But chances are, they have a buggy piece of poo poo toy language that's painfully difficult to work in and will have you craving death after a week. [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. New Yorp New Yorp fucked around with this message at 15:25 on Mar 1, 2013 |
|
#
?
Mar 1, 2013 15:22
|
|
|
bobthecheese posted:I've seen, a number of times, a password being salted with not only a system-wide salt, but also the username. This adds the security of a good salt, ... I've never been shown evidence as to why this is a bad thing. What's so hard about storing high-entropy salts adjacent to passwords? But I suppose it's a silly question, as anyone who actually knows what they're doing is using a well-vetted library, so all the roll-your-own approaches are going to be amusingly wrong.
|
|
#
?
Mar 1, 2013 15:23
|
|
|
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. I'm wary of telling beginners about NIH, because they don't have the experience yet to tell the difference between a useful tool and an external dependency. There's a continuum and it's bad to be too close to one extreme, for sure.
|
|
#
?
Mar 1, 2013 15:46
|
|
|
Why, every time anything related to crypto comes up in this thread, is the optimal solution ignored in favor of discussing the best lovely, broken implementation? USE SCRYPT OR BCRYPT. That is the answer. Do not store salts and hashes next to each other unless you fall into a time warp to 2002, and definitely do not roll your own solution that involves hashing together some metadata along with a system-wide salt and the password jesus loving christ.
|
|
#
?
Mar 1, 2013 15:57
|
|
|
It's gone full circle, hackers expect passwords to be hashed with bcrypt/scrypt so the safest solution is to store passwords in plaintext and hope they don't notice.
|
|
#
?
Mar 1, 2013 16:02
|
|
|
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.
|
|
#
?
Mar 1, 2013 16:22
|
|
|
Bunny Cuddlin posted:USE SCRYPT OR BCRYPT. That is the answer. Do not store salts and hashes next to each other Bcrypt stores the salt as part of the hash. That kinda qualifies as right next to it as well. Or are you suggesting we invent our own variant of bcrypt? Edit: The salt is no more secret than the hash itself. The purpose of the salt is to prevent rainbow table attacks. Hiding the salt away is an exercise in security by obscurity at best, since if you can obtain one of the datasets you can obtain the other as well; the system checking the passwords certainly needs both. nielsm fucked around with this message at 16:35 on Mar 1, 2013 |
|
#
?
Mar 1, 2013 16:32
|
|
|
If you need to ask a question about where to store salts, use a library that handles things for you. It's certainly gonna be better at it than you 
|
|
#
?
Mar 1, 2013 16:37
|
|
|
nielsm posted:Bcrypt stores the salt as part of the hash. That kinda qualifies as right next to it as well. Yes, if you choose to interpret what I said to make the least sense, you're right. I know how bcrypt works; I'm saying store the output of bcrypt, not hash the password with some other scheme and store the salt next to it separately. nielsm posted:Edit: The salt is no more secret than the hash itself. The OH WORD????????
|
|
#
?
Mar 1, 2013 16:38
|
|
|
How is this discussion still going on? Unless it is your full time job to come up with rock solid security/crypto libraries, do not bother trying. You will fail. If you are in a position to fix a weak login system, don't half-rear end it. Use the industry's current best system, and plug in it as best as you can so you can rip it out again in a few years when it is broken. If you have something in place already that isn't horribly broken - fine, leave it. If you are storing plaintext passwords in the database - I hate you. 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.
|
|
#
?
Mar 1, 2013 16:55
|
|
|
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. Well, I all my passwords are ungodly complex, even (or especially) the unimportant ones. I let Keepass worry about it. I have no idea what all but a few of my passwords are.
|
|
#
?
Mar 1, 2013 17:11
|
|
|
Wheany posted:Well, I all my passwords are ungodly complex, even (or especially) the unimportant ones. I let Keepass worry about it. I have no idea what all but a few of my passwords are. My simple passwords are longer than 20 characters and contain mixed case, numerics, and symbols. By "ungodly complex" I mean something truly heinous and impossible to remember. Since they'll email it to me whenever I need it, I don't really care what it is and I just change it again the next time. Edit: I should probably use a password service like you say, but I have some irrational tinfoil hat problem with them. Yes I know this goes against most of what I was just arguing for.
|
|
#
?
Mar 1, 2013 17:18
|
|
|
Bunny Cuddlin posted:Why, every time anything related to crypto comes up in this thread, is the optimal solution ignored in favor of discussing the best lovely, broken implementation? Because coming up with solutions that you think might be safe and having your solutions shot to pieces by someone else is a good way to learn and grow? Also, I saw the same (self-contradicting) thing in your post as nielsm because we both assigned the least complicated literal interpretation to your words, I guess?
|
|
#
?
Mar 1, 2013 17:23
|
|
|
Munkeymon posted:Also, I saw the same (self-contradicting) thing in your post as nielsm because we both assigned the least complicated literal interpretation to your words, I guess? That interpretation only makes sense if you're assuming I don't know how bcrypt works. Which you were, for the same reason you think you can come up with something as good as/better than bcrypt: All developers are narcissists who think they're smarter than they are and suspect everyone else knows nothing.
|
|
#
?
Mar 1, 2013 17:35
|
|
|
Bunny Cuddlin posted:That interpretation only makes sense if you're assuming I don't know how bcrypt works. Which you were, for the same reason you think you can come up with something as good as/better than bcrypt: All developers are narcissists who think they're smarter than they are and suspect everyone else knows nothing. Wrong on both counts, actually. Edit: well, aside from the narcissism, which a lot of people do need to have beaten out of them. Edit 2: Just to clarify, I thought you knew how (b|s)crypt work and was fairly confused as to why you'd say what I thought you were saying. Munkeymon fucked around with this message at 18:00 on Mar 1, 2013 |
|
#
?
Mar 1, 2013 17:39
|
|
|
Munkeymon posted:Because coming up with solutions that you think might be safe and having your solutions shot to pieces by someone else is a good way to learn and grow? This isn't a scenario where this is even close to a good idea. The problem space for crypto is immense and people with multiple phDs are routinely expanding it and destroying all the old "knowledge". It's literally a field where unless you have made serious, concerted study of it under well-known names already in the field, you will NEVER make any meaningful progress or contributions. Asking simplistic questions and trying to find the best practices from first principles is stupid and will never work or provide any benefit at all. You aren't learning anything of value. If you want to understand why some thing is the way it is, start reading white papers and taking courses.
|
|
#
?
Mar 1, 2013 17:40
|
|
|
teamdest posted:This isn't a scenario where this is even close to a good idea. The big mistake in security/crypto is making game-time decisions about which methods to use and/or implementing with insufficient knowledge. But there's no harm in reasoning about it as a mental exercise. However, the actual code should be left to multi-PhD experts. Edit: There's nothing fundamentally wrong with the description of credentials storage as "hash(password, unique_random_high_entropy_salt)" except that the hash functions traditionally used are computationally "too simple" such that brute force techniques are now cost and time feasible, but replace "hash" with PBKDF2/bcrypt/scrypt and it's the same fundamental idea. Furthermore, there do exist legacy systems with security implementations prior to 1999, lots of them. At best, folks can gut and replace them as they come across, but there's still knowledge to be had in understanding particular vulnerabilities of any one deficient system. ExcessBLarg! fucked around with this message at 18:00 on Mar 1, 2013 |
|
#
?
Mar 1, 2013 17:48
|
|
|
teamdest posted:This isn't a scenario where this is even close to a good idea. The problem space for crypto is immense and people with multiple phDs are routinely expanding it and destroying all the old "knowledge". It's literally a field where unless you have made serious, concerted study of it under well-known names already in the field, you will NEVER make any meaningful progress or contributions. Asking simplistic questions and trying to find the best practices from first principles is stupid and will never work or provide any benefit at all. You aren't learning anything of value. If you want to understand why some thing is the way it is, start reading white papers and taking courses. That approach isn't going to encourage people to think critically about their own ideas, which I'm kind of a fan of. It's going to convince people that they know their crypto poo poo and can totally implement <whatever> system by hand without any of those pazy-assed libraries the uneducated plebs use. Basically, it's the (what I think of as) "isolated academic" method that often leads to the narcissism that Bunny Cuddlin was referring to.
|
|
#
?
Mar 1, 2013 17:57
|
|
|
I'm sort of tired of the stigma as treating crypto as some black magic and deferring all sense to learn more about it, and just "use bcrypt/scrypt". I think the people in here are totally reasonable adults, and know that learning about it doesn't mean using it in production, or implementing our own systems. Useless anecdote: My first project when I was learning about multimedia (compression, video formats, etc.) was writing a JPEG encoder/decoder pair. It will never see the light of day outside my own private hard drive, and I know not to ever use it in production (it's slow because it uses accurate math instead of lookup tables, etc.) but it was an excellent learning experience. Cryptography is a very interesting subject for me, and I've read a lot about it and written some code for fun and learning. That doesn't mean I'll invent my own scheme and post it up on the wall. It does mean that I can think of immediate flaws in other's plans, though. Simple puzzle: we recently inherited some code that did a Diffie-Hellman Key Exchange over an insecure channel without any authentication. Why is this a bad idea?
|
|
#
?
Mar 1, 2013 18:16
|
|
|
By all means learn about it - it is damned interesting stuff. Just don't use your homegrown solution in place of something proven. You sound perfectly rational to me. Edit: and the answer to your puzzle is a basic man in the middle attack. armorer fucked around with this message at 18:24 on Mar 1, 2013 |
|
#
?
Mar 1, 2013 18:20
|
|
|
Suspicious Dish posted:I'm sort of tired of the stigma as treating crypto as some black magic and deferring all sense to learn more about it, and just "use bcrypt/scrypt". I think the people in here are totally reasonable adults, and know that learning about it doesn't mean using it in production, or implementing our own systems. it is not to say that it is black magic, but it's really easy to come up with a system that you don't know how to break. Really, really easy. I have no problem with homebrew crypto for learning, but security is one of those things where it's better to assume people will do stupid things.
|
|
#
?
Mar 1, 2013 19:15
|
|
|
armorer posted:My simple passwords are longer than 20 characters and contain mixed case, numerics, and symbols. By "ungodly complex" I mean something truly heinous and impossible to remember. Since they'll email it to me whenever I need it, I don't really care what it is and I just change it again the next time.
|
|
#
?
Mar 1, 2013 19:25
|
|
|
What is the general opinion here about forcing users some password variety? I literally think the worst thing about software (the biggest Coding Horror) is people forcing on user mixing uppercase and lowercase letters. I could remember that is written SciTE and or MySQL and REST, but I cant remember uVBw45T to save my life. I can live with minimal 8 letters passwords, forced mixing numbers and letters, but having to include a uppercase letter push me the wrong way.
|
|
#
?
Mar 1, 2013 19:34
|
|
|
No Safe Word posted:Uh, I hope not. At that point you certainly ought to change it immediately anyway. Did you miss the whole discussion? I was specifically talking about places that email you your password in plain text. Edit: This post was colder than it needed to be, sorry about that. But yeah - I was specifically bitching about places that keep your password in plaintext in the database so they can mail it to you when you forget it. armorer fucked around with this message at 19:42 on Mar 1, 2013 |
|
#
?
Mar 1, 2013 19:38
|
|
|
Having no experience with reality whatsoever, I'd say ideally design some password cracker (specifically, the part that iterates over a dictionary including spelling and letter/number variations and everything, then figure out how long it would take for the cracker to crack that user's password, and require the strength to be above a certain number. Or just put one of those javascript strength meters on the page, and have a minimum length.
|
|
#
?
Mar 1, 2013 19:38
|
|
|
armorer posted:Did you miss the whole discussion? I was specifically talking about places that email you your password in plain text. Ah I did then, sorry.
|
|
#
?
Mar 1, 2013 19:44
|
|
|
Tei posted:What is the general opinion here about forcing users some password variety? For example, a 64-character random hex string is a perfectly sufficient password. If your password requirements fail to accept that, your requirements are broken. Essentially, if the password can't be trivially broken with a sophisticated dictionary attack, it's good.
|
|
#
?
Mar 1, 2013 19:55
|
|
|
Tei posted:What is the general opinion here about forcing users some password variety? I'd prefer enforcing a certain minimum length over forcing mixing upper and lower case or any of that nonsense. In the end, though, it's about balancing the cost (financial and otherwise) of a password being broken with the cost of an increased amount of user fatigue regarding remembering and resetting passwords.
|
|
#
?
Mar 1, 2013 19:55
|
|
|
Minimum password length, make sure password is not same as username or the alias of an email, ban top 100 most common passwords. When I worked at AT&T, their password enforcement rules were really stupid. Like you needed a number, some minimum amount of an uppercase letter, and a non-alphanumeric character and some other weird rules. Oh yeah and their Javascript "validator" just denied your password without giving a reason. I had to look through the code to see what the passsword enforcement was.
|
|
#
?
Mar 1, 2013 20:36
|
|
|
Strong Sauce posted:Minimum password length, make sure password is not same as username or the alias of an email, ban top 100 most common passwords. I had to do the same thing for Comcast on their old site. My college's web portal had a pretty healthy requirement for passwords: minimum 16 characters. However, it was also maximum 16 characters.
|
|
#
?
Mar 1, 2013 21:09
|
|
|
|
| # ? May 17, 2024 16:31 |
|
|
Complexity requirements are pretty worthless if you have centrally-set passwords, and enrage me here. 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.
|
|
#
?
Mar 1, 2013 21:40
|
|
