61–70 of 112 posts
Note that if you store your passwords in a fast hash format like salted SHA1, an attacker with 32MM database rows can publish a very credible sample of usernames and passwords, and leave you scrambling to explain how the breach isn't really as bad as it looks. Not a great position to be in. The right answers to this problem are BCrypt, SCrypt, PBKDF, or (at a minimum) salted "stretched" SHA1, iterated many thousands…
Earlier quoted context omitted.
I certainly get why a slower hash would curb brute force attacks, but when I'm talking about unique salts, slowing down the hash is not the purpose I have in mind. If you have a table of 32 million hashed passwords with no salt (or they have the same salt and you know what it is), you can try a bunch of combinations, take the resulting hash, and look it up in the hashed password database. If you try the password "foo…
Every time I bring this up, which is often because it is, apparently, all I ever talk about here, people misconstrue what I'm saying as some kind of argument against "salted" hashes. It is true that not even bothing to randomize your hashes is worse than doing so. But when we're talking about degrees of grave badness, I stop being super interested in the conversation. If, for reasons passing my understanding, you are…
Let me put it this way: give me a database of 32 million username/password_hash combinations and the hash(password) function used and I can give you a valid username/password combination fairly quickly. Even if the hash function takes 10 seconds, because chances are one of those 32 million users has used "password" as a password, and it will only take me 10 seconds to compute the hash and find out which ones did.
If instead you give me 32 million username/password_hash/salt combinations, and the hash(password, salt) function used, just to list the users who have the password "password" will take 10 years.
Earlier quoted context omitted.
It happened (storing in plaintext, not losing the actual passwords): http://www.jgc.org/blog/2009/05/can-you-trust-37signals-with... We've covered 37signals poor approach to security before: http://news.ycombinator.com/item?id=804257 It's my understanding that they've since reformed. I'd be interested in what books you think they've written that provide credible security advice. Blind "fanboyism" (if I may invent a w…
Both of those links are not proof of any lax security at 37signals. The first link makes the assumption that the ability to email a user's password means the passwords are in plain text. There is such as thing as secure two-way encryption. (Granted, if the hacker gets the encryption key, you're hosed.) You can read more about that in the comments on that blog. [ignore] The second link is about a security problem in r…
So, is there any less sensitivity (security-wise) regarding the key, instead of the password?
Note that if you store your passwords in a fast hash format like salted SHA1, an attacker with 32MM database rows can publish a very credible sample of usernames and passwords, and leave you scrambling to explain how the breach isn't really as bad as it looks. Not a great position to be in. The right answers to this problem are BCrypt, SCrypt, PBKDF, or (at a minimum) salted "stretched" SHA1, iterated many thousands…
What do you think about the Whirlpool hashing algorithm?
Earlier quoted context omitted.
Every time I bring this up, which is often because it is, apparently, all I ever talk about here, people misconstrue what I'm saying as some kind of argument against "salted" hashes. It is true that not even bothing to randomize your hashes is worse than doing so. But when we're talking about degrees of grave badness, I stop being super interested in the conversation. If, for reasons passing my understanding, you are…
I'm not misconstruing your argument as against salted hashes, but as downplaying the advantages of using a unique salt over an install-specific salt (not sure that's the best term, but I'm referring to the type of salt you might find in a config.py file). Let me put it this way: give me a database of 32 million username/password_hash combinations and the hash(password) function used and I can give you a valid usernam…
The attack you're talking about --- searching for a radically reduced set of passwords --- is so fundamental to password security that you don't need any crypto to do it. Just open 50 concurrent connections to the login page and rip through the user list. At the same time, with the default BCrypt cost factor, just doing the password 'password' takes 1000 hours against a 32MM row data set.
Earlier quoted context omitted.
There is a difference between storing plaintext passwords and actually losing them, and as much as I hate to give someone a pass on insecure password storage (it is, apparently, all I ever talk about here), you have to be intellectually honest. And, like I say every time this comes up, FedEx and several banks also store plaintext passwords. 37signals no longer stores easily attacked passwords.
There is a difference between storing plaintext passwords and actually losing them, and as much as I hate to give someone a pass on insecure password storage (it is, apparently, all I ever talk about here), you have to be intellectually honest. I was intellectually honest. I explicitly said they didn't actually lose them. 37signals no longer stores easily attacked passwords. I was under the impression that this was t…
The "honesty" comment wasn't directed to you, but it's obvious why you would think it was. Sorry.
Earlier quoted context omitted.
Salts are usually stored in two components; one is in the database and unique per row, to prevent cracking multiple rows at once. The other component is in a config file in the server -- it adds a constant number of bytes to the input for any brute force attempt. If an attacker can achieve a root login to your server, then they can read your config file, but they can also just change the login form to email them pass…
If your webserver machines are so secure, why put them in the database at all? Just store the passwords on disk there, rsync the password file across all machines and you're set. I kid, but I really think you and tptacek just have different standards. tptacek's is higher.
Well, that and the obnoxious trick question.
Earlier quoted context omitted.
There is a difference between storing plaintext passwords and actually losing them, and as much as I hate to give someone a pass on insecure password storage (it is, apparently, all I ever talk about here), you have to be intellectually honest. I was intellectually honest. I explicitly said they didn't actually lose them. 37signals no longer stores easily attacked passwords. I was under the impression that this was t…
Either they haven't gotten to you in the rollout yet, or they aren't doing Backpack (which would surprise me). The "honesty" comment wasn't directed to you, but it's obvious why you would think it was. Sorry.
Given your history of quality and logical posts, I pretty much knew the comment wasn't directed towards me. I just wanted to go on record to be sure. I'm sorry as well, I should have just let it fly.
Either they haven't gotten to you in the rollout yet, or they aren't doing Backpack (which would surprise me).
They're launching unified accounts soon for all services (you have to pick a new user name and password if I remember correctly). Perhaps this is when they'll roll out the password security? Seems like a logical time to me.
This is just some amateur hour shit. They're a well established and well funded company. How do venture funds not do better technical due diligence(or any at all)? I wouldn't release an app for 32 of my friends to test, let alone 32 million people to use with plain text passwords. Enough of my bitching, because it's inaction. Now for words of action/openings for suggestion: How do we make sure companies don't do dumb…
Because it's not seen by "management" or "VC's" as a priority. Extra programming is seen as a time and monetary cost, not a necessity. One company I worked for used plain-text for customer passwords and mandated Microsoft technology in the same breath. When I talked to the lead tech, I got a shrug. Not because of lack of technical smarts but politically tied hands from management. When I contacted the MBA minted CEO I got a blunt - "it's not a problem, don't worry about it".
A physical loss is perceived more
tangible than something ephemeral.
Earlier quoted context omitted.
"Agile Web Development With Rails", Chapter 11, Administration
Here's the sample code they give in that chapter: def self.encrypted_password(password, salt) string_to_hash = password + "wibble" + salt # 'wibble' makes it harder to guess Digest::SHA1.hexdigest(string_to_hash) end They are using SHA1 with a salt, the exact method that security experts recommend against when storing passwords: http://news.ycombinator.com/item?id=995645 . And obviously they didn't even use this inse…