Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Are You Sure SHA-1+Salt Is Enough For Passwords?

CmdrTaco posted more than 3 years ago | from the good-enough-for-govt-work dept.

Security 409

Melchett writes "It's all too common that Web (and other) applications use MD5, SHA1, or SHA-256 to hash user passwords, and more enlightened developers even salt the password. And over the years I've seen heated discussions on just how salt values should be generated and on how long they should be. Unfortunately in most cases people overlook the fact that MD and SHA hash families are designed for computational speed, and the quality of your salt values doesn't really matter when an attacker has gained full control, as happened with rootkit.com. When an attacker has root access, they will get your passwords, salt, and the code that you use to verify the passwords."

cancel ×

409 comments

Sorry! There are no comments related to the filter you selected.

First Post! (-1)

ThePortlyPenguin (225165) | more than 3 years ago | (#35149560)

First post!

Re:First Post! (1)

Anonymous Coward | more than 3 years ago | (#35149640)

May I be the first to congratulate you on your insightful, interesting and well written post. It's amazing you managed to do all that, and do it before anyone else. You really do make /. what it is. Thanks!

Re:First Post! (3, Informative)

e70838 (976799) | more than 3 years ago | (#35149938)

In fact the first post is almost as much interesting as the whole story. Melchett does not understand very well the purpose of salts and want to share with us its ignorance.
Salts are a necessity: without salt, you would be able to identify very fast two users having the same password. Without salts, you would be able to find a password faster when you have more users. As a result, the size of the salt shall be related to the number of encrypted passwords you are trying to protect from cracking.

If you are trying to crack a single account, salt does not change anything. The purpose of salt is not to increase the security of a single account, but to avoid the reduction of security that would occur when you have many accounts.

Re:First Post! (2)

WrongSizeGlass (838941) | more than 3 years ago | (#35149796)

First post!

Your failure to properly encrypt your post has left it vulnerable to many eyes. Maybe you should have RTFA?

News at 11 (0)

Anonymous Coward | more than 3 years ago | (#35149564)

This just in, passwords don't protect against people with root access.

Re:News at 11 (0)

commodore6502 (1981532) | more than 3 years ago | (#35149760)

"FILM at 11" (it takes time to develop the film, so that's why it can't be shown at 6).

Re:News at 11 (1)

Stormwatch (703920) | more than 3 years ago | (#35149912)

The first time I heard that "film at 11" thing, I thought they meant airing a movie at 11 PM.

Re:News at 11 (-1)

Anonymous Coward | more than 3 years ago | (#35149926)

Language change and evolve. News at 11.

Re:News at 11 (5, Informative)

ObsessiveMathsFreak (773371) | more than 3 years ago | (#35150000)

This isn't about passwords, it's about using hash values to protect passwords even from people with the root password. Basically, not even root should be able to figure out any users password.

Normally this is done by never storing the users password, only a hash of the users password, it's MD5 value say. Now the user enters their password, this is hashed, and that value compared to the stored hash. We could talk about collisions etc, but lets assume this works for now. User can get in with the right password, but not even root knows what this is just by looking at the hash database.

Unless of course rootâ"or the attacker that has gained rootâ"has a precomputed table of hash values. Then they need only look up the hash and obtain the password directly. To prevent this, systems use "salts", random integers/strings, appended/XORed to the password before the hash is computed. In theory then, an attacker would need to generate a different hashtable for each individual system compromised. Infeasible, or so we think.

He's where TFA comes in. MD5 and SHA1 are optimised to some extend for speed. Now, suppose the attacker has gained root and now knows the salt. How long will it take to generate a hashtable which can be looked up to find user passwords. TFA argues that this will now take only 33 days on a single machine using GPU computation. That's ~24 hours with less than 50 GPUs. Salt or not, these hashes are crackable in hours, not years.

So basically, the speed of MD5 and SHA1 hashes is actively working against computer security by making computing hashtables easier. TFA argues that a more computationally difficult hash scheme is needed, subject to certain criteria, and offers the PBKDF2, Bcrypt, and HMAC algorithms as potential alternatives. You could also throw, say, the three body problem with initial conditions at the computer instead.

Basically, hashing will protect against people with root access, but only if the hashing algorithm is computational difficult.

Security cookbook? (1)

Compaqt (1758360) | more than 3 years ago | (#35149570)

Does anybody have a link for a security cookbook that covers this and other security topics while taking in to account the latest developments re: MD5 and friends, cross-site scripting, SQL injection, and other problems of the web-based app age?

Re:Security cookbook? (3, Informative)

Errol backfiring (1280012) | more than 3 years ago | (#35149668)

I found this book useful. It does not go too deep, but just deep enough: http://innocentcode.thathost.com/ [thathost.com]

Re:Security cookbook? (0)

Anonymous Coward | more than 3 years ago | (#35149806)

Woh, spammers are getting organised these days.

Wait, what? (4, Informative)

Anonymous Coward | more than 3 years ago | (#35149578)

Why is this even a question? Use bcrypt [codahale.com] , always. (Preferably using the $5$ or $6$ extensions.)

Re:Wait, what? (3, Informative)

vlm (69642) | more than 3 years ago | (#35149726)

Why is this even a question? Use bcrypt [codahale.com] , always. (Preferably using the $5$ or $6$ extensions.)

mysql only offers AES, DES, MD5, and SHA... So... for at least a certain subset of developers, thats what they're going to use.

I'm not saying they're correct to do so, I'm just explaining why they will not even consider your suggestion, because they have architectural problems, for them its not as simple as search and replace all calls to md5() with bcrypt().

Re:Wait, what? (1)

truthsearch (249536) | more than 3 years ago | (#35149858)

Pulling the one database call into the application code shouldn't be difficult if the system is architected well. In the framework I maintain it only requires changes to two small functions.

Re:Wait, what? (4, Informative)

Stellian (673475) | more than 3 years ago | (#35149842)

While most people know enough about security to avoid a plain password hash, very few people know how vulnerable common key derivation functions truly are. Things like PBKDF2, bcrypt and MD5-crypt widely used for example in Linux shadow file or in TrueCrypt give only a linear advantage over a salted plain hash. 5000 MD5 repetitions might sound like great security from a brute force perspective, but the asymptotic hardware cost of brute-forcing such a password is fairly small. The cost to break your 8 letter bcrypt password is in the hundreds of dollars, assuming enough passwords are cracked to justify a hardware cracker. I can almost bet NSA has a multi-million dollar hardware cracker that can brute-force your Linux or TrueCrypt password, assuming it has less than about 50 bits of entropy. Very few people are capable or willing to use truly safe passwords with 100bit+ entropy.

I know of only one strong key derivation algorithm that forces the attacker to scale it's hardware cost at the same rate as the software slowdown: scrypt [tarsnap.com] . So by all means, don't use bcrypt, use scrypt.

The issue is completely different in a webserver, that probably can't spend 1 second of CPU time whenever a user logs in. Is such cases a hash + salt is all that you can realistically expect if a dedicated authentication machine does not exist. At least try to combine them safely using a HMAC, not some home-grown SHA1(salt+password) scheme.

Re:Wait, what? (2)

MightyYar (622222) | more than 3 years ago | (#35149860)

Use bcrypt

Forgive me for being dense, but the advantage of bcrypt is that it's slower? If that is the case, why not just run your MD5 or whatever hashes in a loop 50 or 60 times to get the same performance hit?

Re:Wait, what? (0)

Anonymous Coward | more than 3 years ago | (#35150038)

Exactly !!! (altough you are several orders of magnitude off, should be more like 10^5 times).

Bashing on hash functions because they are fast is retarded. No matter what you do, if the password can be guessed, you are screwed anyway. There is nothing that prevents building a scheme as secure as bcrypt on top of a hash function.

The post isn't really about password hash strength (0)

Anonymous Coward | more than 3 years ago | (#35149588)

It's about making sure you don't allow root access to your system.

Re:The post isn't really about password hash stren (1)

jellomizer (103300) | more than 3 years ago | (#35149880)

Normally if the person has enough access to see the hashed Password they have enough access to change it, with their own. No need to decrypt it just change it with your own... When you are done you past it back in. The purpose of MD5 SHA or whatever isn't to keep your password as an uncrackable password. It is about keeping it encrypted enough to keep us from seeing peoples passwords. So when they go I don't know my password you can't just look it up and give it to them. You will need to go threw a password reset process.

well, geeesh.... not anymore I don't! (0)

Anonymous Coward | more than 3 years ago | (#35149596)

well, geeesh.... not anymore I don't!

Passwords (2, Insightful)

betterunixthanunix (980855) | more than 3 years ago | (#35149606)

Easy solution: do not rely on passwords. As TFA says, people are very bad at generating random passwords, so why are we relying on them to do so? Use cryptographic authentication methods, and a lot of problems will be solved.

Then again, it has been so hard to get people to start using IPv6, I expect that the effort it would take for people to change the time honored method of authentication is simply too large.

Re:Passwords (1)

drinkypoo (153816) | more than 3 years ago | (#35149722)

The real problem is that there is no means of remote authentication that cannot be faked in one way or another. Unless you figure out how to fingerprint the soul this is going to be an ongoing problem basically forever. The best thing you can do is use multi-factor authentication but that provides new opportunities for user frustration so we tend away from it. A keyfob can be lost or stolen. The machine a private key resides on can be compromised. All you can do is raise the bar and pray.

Re:Passwords (1)

betterunixthanunix (980855) | more than 3 years ago | (#35149772)

Raising the bar is the point; true, the machine on which the private key resides might be compromised, but this is no worse than the situation with passwords (where the machine on which a password is entered might be compromised). On the other hand, users should not have to worry that a server could be compromised, and they should not have to worry that one compromised server can lead to compromised accounts on other systems. It is much easier for users to look after things they possess -- a card, a thumb drive, a computer -- than to try to generate a secure password that they can remember.

Re:Passwords (2)

antifoidulus (807088) | more than 3 years ago | (#35149832)

and if someone breaks into my house and steals my dongle? What then? I have to have some way of going and getting a new one and inactivating the old one. How can I do that? How can I prove that I am the original owner? I'm going to need some type of security mechanism, such as a.....PASSWORD!

Re:Passwords (2)

betterunixthanunix (980855) | more than 3 years ago | (#35149896)

Or you could tell your bank to revoke your key, in person (presumably there is a system for identifying yourself in person), and to register a new public key for you; this has the added advantage of helping them track down people who might try to use your old key. If meeting in-person is not possible (e.g. with Amazon or EBay) you could call them and tell them the fingerprint for your new key, or perhaps even just have them deactivate your old account and then create a new one.

This is basically the process I use with SSH keys: people who lose their private keys (often by formatting their drives) have to come to me and give me a new public key to log in with. It is slightly less convenient than a password, but all I need to do is look through the logs of endless attempts to brute force passwords to remind myself that it is worth it.

Re:Passwords (2)

Carewolf (581105) | more than 3 years ago | (#35149988)

No, the real problem is that even if you had perfect authentication that couldn't be faked, you could still have stupid, malicious or simply corrupt employees. The entire idea of trying to restrict information to specific people is flawed. That doesn't mean it is a bad idea, but don't be surprised that it isn't perfect, and don't worry about complete perfection. You will always have way bigger security holes than technological ones.

What is the solution: There is no solution, only semi-perfect prevention.

Re:Passwords (2)

Wolvenhaven (1521217) | more than 3 years ago | (#35150036)

If you fingerprint the soul and use it for authentication, you'll be excluding politicians and lawyers from any services you offer.

Re:Passwords (1)

Anonymous Coward | more than 3 years ago | (#35149738)

Hopefully I don't come across as trolling here, but really, actually, what alternatives do you suggest? Let's say you're Facebook - you've got millions of ordinary people using your site; what choices do you really have?

Let's assume two scenarios... 1) you have limitless money and resource to implement anything you so choose, and your user base is as well educated as the average slashdotter. And then, 2) you're an organisation with commercial pressures like everyone else, and you're dealing with the general public.

I understand that my company can use something like a two factor solution to connect me to the VPN or what not, but what can you really do with the general public? (One poster later on suggests calling it a 'pass phrase' rather than 'password' and requiring at least three words in it (or whatever) to increase the search space. I get that's an option, but it's still a 'password').

Re:Passwords (0)

Anonymous Coward | more than 3 years ago | (#35149874)

Maybe seeing it as a "pass phrase" would allow people to have more complex passwords. A lot of people I know have single work passwords and have trouble with them. But if they just thought to type a sentence into the password box, they'd have something hard to reproduce exactly ( barring obvious passwords ) and virtually impossible to realistically brute force in a reasonable amount of time, while being incredibly easy to remember and far more secure.

"There are several thousand different ways to type a password, but this one is nice!"

Re:Passwords (1)

Joce640k (829181) | more than 3 years ago | (#35150160)

Why do you think that asking people to choose a "phrase" is going to be more secure than asking them to type a word? It just means they'll just type "my password" instead of "password", "abc 123" instead of "abc123" and "i love you" instead of "iloveyou".

The problem isn't the number of letters, it's the users.

Re:Passwords (2)

betterunixthanunix (980855) | more than 3 years ago | (#35150040)

It is somewhat ironic that you should bring up Facebook, which is the first website that comes to mind when I think about the problems with passwords. Have you forgotten what one of Zuckerberg's first uses for Facebook was? I have not:

http://www.businessinsider.com/how-mark-zuckerberg-hacked-into-the-harvard-crimson-2010-3 [businessinsider.com]

This is one of the biggest problems with passwords: you often wind up sending a password to some unknown system that could be doing a number of things with it (like displaying it to Mark Zuckerberg). Combined with the fact that people routinely use the same password on multiple systems, and may mistakenly enter the password for one system when logging in to another, I would say passwords are almost a security liability.

Here is the alternative, and it is very common to do this with ssh: use public key authentication. I can leave my public key on numerous systems, and not worry about some account being compromised. My computer generated the key; computers are good at generating big random numbers. I can also choose my security level; if I want a search space of a certain minimum size, I can generate an RSA key of a corresponding size (likewise with DSA/EC/etc.). There are some annoyances with public keys, but in my opinion, they are far better than passwords.

Re:Passwords (0)

Anonymous Coward | more than 3 years ago | (#35149754)

Easy solution: do not rely on passwords. As TFA says, people are very bad at generating random passwords, so why are we relying on them to do so? Use cryptographic authentication methods, and a lot of problems will be solved.

Then again, it has been so hard to get people to start using IPv6, I expect that the effort it would take for people to change the time honored method of authentication is simply too large.

+1

Some resources for RSA public key encryption libraries using javascript:
https://www.pidder.com/pidcrypt/
http://www.github.com/jas-/jQuery.pidCrypt/ (this uses the pidCrypt RSA libraries and has a server side class to generate public/private keys)

Re:Passwords (1)

Anonymous Coward | more than 3 years ago | (#35150084)

Why not use an authenticator? Either a cheap hardware device like a keyfob, or a phone app - something removed from the desktop machine used to login. It's worked great for Blizzard - in fact it improves security so much that they offer a lot of incentives to use one. (for those unfamiliar with the term, it generates a code based on the current time, and the user's account details - the code is only valid for 60 seconds or so I believe. The user must enter this code in addition to their login and password) If the service providing verification of the authentication codes was on a device not accessible via the internet (or only the single verification service were available) then even if all the accounts were cracked, they'd still be mostly useless to the crackers.

I'm amazed that banks don't use something similar on their sites, to be honest. I'd definitely use one, even if I had to pay to obtain a device.

Re:Passwords (1)

PRMan (959735) | more than 3 years ago | (#35150086)

The point of the article (since I read it) is that you should limit attempts per second. They recommend 10,000/second, but when I code I recommend one. Why would anybody need to login to the same username more than once per second? If the point is stopping automated login hacking, it accomplishes the job.

Re:Passwords (1)

PRMan (959735) | more than 3 years ago | (#35150134)

Now, note that these are failed logins only. Successful logins do not get timed, in case you were wondering about B2B web services or something.

Re:Passwords (1)

Idimmu Xul (204345) | more than 3 years ago | (#35150150)

I have to use an RSA key fob now to sign in to several bits and pieces and it's REALLY EXCITING!

I feel a bit like a spy typing in different secret codes every day.

Uhhh, yeah? (0)

WiglyWorm (1139035) | more than 3 years ago | (#35149612)

So i guess the moral of the story is salt your passwords and make sure you have a strong root password? We can add some more common sense in there like "keep your os up to date", "don't give your password out to people", and "that nigerian prince isn't going to pay up"? I can has security eckspurt?

Re:Uhhh, yeah? (1)

Anonymous Coward | more than 3 years ago | (#35149706)

No, the moral of the story is to use a hash that takes a long time to compute.

My entire system is encrypted, and when the passphrase is hashed, 2**23 rounds of SHA-256 are used (takes something like 13 seconds on my P4 2.4). Plus, of course, a salt is used.

This won't protect against stupid passwords, but it will really help against brute-force.

Re:Uhhh, yeah? (1)

PitaBred (632671) | more than 3 years ago | (#35149830)

It's a good thing you're the only user. How big of an authentication server would you have to have to just handle a 100 person organization? 1000? 100,000?

Re:Uhhh, yeah? (2)

magsol (1406749) | more than 3 years ago | (#35149780)

No, the moral of the story is to not do any of those things, since your box is going to get hacked anyway.

The problem is people (3, Interesting)

plover (150551) | more than 3 years ago | (#35149626)

Like TFA says, worry more about the passwords people choose. It doesn't matter if you use SHA-1, MD5, or an HMAC, if the idiot types "password" for his password, it's going to be discovered on the first loop of anyone's "common passwords" list.

One way to get people to comply better is simply to refer to it as a "passphrase" instead of a "password". Maybe enforce "three word minimum" or something. Even if they just use a line from a movie, it's increased the search space dramatically over a single word.

Re:The problem is people (5, Insightful)

vlm (69642) | more than 3 years ago | (#35149660)

Like TFA says, worry more about the passwords people choose. It doesn't matter if you use SHA-1, MD5, or an HMAC, if the idiot types "password" for his password, it's going to be discovered on the first loop of anyone's "common passwords" list.

Its best to go overboard and require a minimum of 15 characters, a mix of upper and lowercase, at least two non-consecutive numbers and at least two punctuation marks. And store then so they can't reuse their previous 20 passwords. That way the users will exclusively save the password in their unsecure browser, unsecure post it notes, or cut and paste from a text file, or the corporate standard database that being an excel spreadsheet. Thats how REAL security pros roll, or so I'm told.

Re:The problem is people (1)

Entrope (68843) | more than 3 years ago | (#35149750)

REAL security pros use multi-factor authentication by storing their master password list in an encrypted file on their rooted/custom-firmware mobile phones. The file is encrypted using a master pass-phrase (factor 1) and the phone will only unlock with a biometric ID (factor 2) and you need the phone to get at the password (factor 3). Bruce Schneier has written all about it!

(It is rather important that your wireless service provider not have administrative access to the device, which is where the custom firmware comes in. And yes, I know having the cell phone doesn't really count in the traditional sense of multi-factor security; the whole thing is a little bit tongue-in-cheek. Most people just need to be harder to attack than their neighbor; relatively few people need to be extremely resistant to attacks, although they are more common in /.'s readership than in the general public.)

Re:The problem is people (1)

bwintx (813768) | more than 3 years ago | (#35149776)

+1

Re:The problem is people (1)

Bert64 (520050) | more than 3 years ago | (#35149828)

You do make a good point, the typical advice given out on password policies can often be detrimental, and the typical implementations used can be flawed.

Most systems don't stop dictionary words.
Even if you're forced to use a *different* password to your previous one, the level of difference typically isn't enforced so password1 can become password2.
Storing a fixed number of previous passwords is flawed as users can keep changing them to roll around, and setting a minimum password age is just a nasty kludge trying to mitigate this problem while causing new ones - much better to store any number of old passwords for a predetermined length of time.
There are also flawed authentication schemes out there which make it possible to authenticate using the hash without needing to crack the plaintext password.

People use the same passwords in multiple places... Even if you choose good strong passwords and some of the places you use it encrypt it with a strong one way hashing algorithm, how do you know how various systems will store your passwords? All it takes is for one to store it weakly and your toast.

Re:The problem is people (1)

plover (150551) | more than 3 years ago | (#35150146)

I wasn't trying to provide a comprehensive list of password composition rules. What I was trying to say is that because we're dealing with people, we have to encourage them to make better password choices. Changing the mindset of people from "password" to "passphrase" or even "pass-sentence" is one place to start. It's an easy way to help average people think of more (number of bytes) data.

Even if it's as inane as "omgilovejustinbieber!", it's probably not found in any hackers' rainbow table (yet.) But if you were to demand a 20 character password, people would be really mad, thinking "I don't know any 20 character words!" With a pass phrase, it's much easier to think of and to explain to users. Your error message can be fairly simple: "Your pass phrase doesn't have enough words for good security. Pick a longer sentence, and use some punctuation."

And yes, you'll always have some people picking "aaaaaaaaaaaaaaaaaaaa." and variants. No scheme is perfect, but neither is security. If you can shift the number of weak passwords in your user base from 75% to 10%, that's a large reduction in your attack surface.

Re:The problem is people (2)

Rosco P. Coltrane (209368) | more than 3 years ago | (#35149686)

Maybe enforce "three word minimum" or something

Wanna bet on the number of people who'll chose "a a a" as a password?

Re:The problem is people (1)

betterunixthanunix (980855) | more than 3 years ago | (#35149702)

Or, you can ditch passwords, and use public key authentication methods. Pick a 3072 bit RSA key, and your search space is suddenly on the order of 2^128 -- I think that should suffice for a while. If you want to be careful, pick an even larger key, perhaps 16384 bits, to protect against possible future improvements in factoring algorithms. The great thing about these methods is that you can rely on a computer to generate the key; computers tend to do a good job at generating random numbers, certainly better than humans.

Re:"Maybe enforce three word minimum" (1)

Joce640k (829181) | more than 3 years ago | (#35149736)

One of the most common passwords of all time is "iloveyou" so I'm not sure that will help.

The trouble with making things foolproof is that fools are very resourceful people...

Re:The problem is people (1)

muckracer (1204794) | more than 3 years ago | (#35149916)

> One way to get people to comply better is simply to refer to it as a "passphrase" instead of a "password".
> Maybe enforce "three word minimum" or something.

Already done here!
Used to have: "MyPassword1".
Now I got: "My passphrase One" :-)

Yet another idiot story. (1)

Anonymous Coward | more than 3 years ago | (#35149674)

Salts just mean they can't use precomputed rainbow tables, salt length should be long enough to make existing rainbow tables useless. This isn't hard.

Re:Yet another idiot story. (3)

tazan (652775) | more than 3 years ago | (#35149898)

The point of the story was rainbow tables are unnecessary, it doesn't matter how long your salt is they can iterate through most of the hashes in a matter of days. If you use a different salt for every account then they would have to repeat the process for each account, which definitely limits the damage, but doesn't make you feel any better if you're the account they are going after. TFA says we need to slow down their ability to iterate through all the possible hashes.

Re:Yet another idiot story. (0)

Anonymous Coward | more than 3 years ago | (#35149974)

But that isn't new, the difference is it can take seconds or it can take days. Fact is, if you've experienced a full breach that would leave passwords exposed you're fucked either way. This story has no purpose.

Re:Yet another idiot story. (1)

SuricouRaven (1897204) | more than 3 years ago | (#35149990)

I wrote a little program that will reverse any MD5 hash produced from a printable string up to five characters in length, and do so in about 1/3 second. I could make it up to six characters easily if I were willing to set up an extra 4TB of storage for the tables. Seven or more, the storage requirements get silly. And it's not a rainbow - no 99.999% chance of success here. If the password is 1-5 characters, it will be broken.

Salting still defeats it though.

Password Security. (1)

Onuma (947856) | more than 3 years ago | (#35149690)

[semi-off-topic?]
Once someone is in your system with root/admin accesses, you're already hosed.

Most users will create the least-secure password which still meets the restrictions you've set upon them - whether that's 8-10 chars with 2 upper/lowercase, 2 digits, and 2 specials or a 16/32/64 digit extravaganza.
My philosophy is to make a very secure password and then keep it written and on my person until I completely memorize it. It doesn't have to make sense, it sure as hell won't be my anniversary or birthday. You've got a much less likely chance of kicking my ass and taking that piece of paper, compared to setting up a script to crack it.

To this day, the most secure form of sending a message is still a live messenger - codes can be cracked and transmissions can be intercepted. People are harder to break.

What you want to use is something that will not be trivial to brute force. Instead of doing 2300 million attempts per second, you want something that limits an attacker to 10,000 or 100,000 attempts per second.

Not being a security guru, why would you even give someone 10k or 100k attempts/second? I'd want to keep that number as low as feasibly possible, per account.

Re:Password Security. (0)

Anonymous Coward | more than 3 years ago | (#35149728)

Not being a security guru, why would you even give someone 10k or 100k attempts/second?

Without RTFA (what, did you expect me to?) I would guess that the point there is that once your database leaks you can't restrict the number of attempts per second.

Re:Password Security. (1)

vlm (69642) | more than 3 years ago | (#35149774)

Not being a security guru, why would you even give someone 10k or 100k attempts/second? I'd want to keep that number as low as feasibly possible, per account.

Attacker sql injected (or whatever) a "select * from passwordstable" and now have a local copy. Then on their local box, or cloud provider, or another victims box / cloud, they crack the passwords table using their own resources. You have no way to rate limit them other than making it computationally intensive. I think you're thinking of something like "fail2ban" on your locally installed app.

Re:Password Security. (2)

John Marter (3227) | more than 3 years ago | (#35149878)

Moreover, you generally have a pretty good intrusion detection system for a password kept on your person. If it has been compromised, you'll know it and can change the password.

They don't necessarily get the salt (2, Insightful)

mysidia (191772) | more than 3 years ago | (#35149694)

When an attacker has root access, they will get your passwords, salt, and the code that you use to verify the passwords."

Not if you encrypt the salt using the password.

Password Hash = SHA256( AES_ENCRYPT( SALT using PASSWORD ) )
Salt Hash = SHA256( SALT )

Authentication: user enters password
Does SHA256 ( AES_DECRYPT ( Password Hash using PASSWORD ) ) equal Salt Hash ?
Yes: Password Entered Correctly
No: Access Denied

Re:They don't necessarily get the salt (0)

Anonymous Coward | more than 3 years ago | (#35149732)

Doesn't making a new password there require knowledge of the SALT?
So if the server was compromised they would have it?

captcha: respond

Re:They don't necessarily get the salt (2, Interesting)

spikenerd (642677) | more than 3 years ago | (#35149814)

Not if you encrypt the salt using the password.

The whole point of salt is to mitigate a dictionary attack. With your approach it would only take one dictionary attack to obtain the salt, and then another one (using the obtained salt) to obtain the password. Thus, you have merely doubled the amount of computation required to obtain the password. In most security philosophies, increasing the required computation by a polynomial factor does not make it more secure.

Re:They don't necessarily get the salt (1)

mysidia (191772) | more than 3 years ago | (#35150030)

The whole point of salt is to mitigate a dictionary attack.

No.... the point of a salt is to prevent optimization of dictionary attacks by using rainbow tables, or making an efficient database of pre-computed common passwords (for example). Common uses of salts do not prevent dictionary attacks, they make them take longer and require more computational power.

With your approach it would only take one dictionary attack to obtain the salt, and then another one (using the obtained salt) to obtain the password. Thus, you have merely doubled the amount of computation required to obtain the password.

Um... I don't know what computational world you live in where requiring TWO dictionary attacks is merely doubling the effort required.

In regards to, dictionary attacking the SHA256( AES_ENCRYPT( SALT using PASSWORD ) )

It's really only one dictionary attack anyways....
SHA256( AES_ENCRYPT( SALT using password guess ) ) eq Password Hash

Once the right password guess is made, the salt is known to the attacker.

Re:They don't necessarily get the salt (2)

0123456 (636235) | more than 3 years ago | (#35150130)

The whole point of salt is to mitigate a dictionary attack. With your approach it would only take one dictionary attack to obtain the salt, and then another one (using the obtained salt) to obtain the password.

How are you going to perform a dictionary attack when the salt is just a random number? For a brute-force attack you need to know that the value you've decrypted is the correct one, and if the value is just a random number you have absolutely no information to tell you whether it's valid.

Re:They don't necessarily get the salt (1)

0123456 (636235) | more than 3 years ago | (#35150184)

Ah, of course you can take the password and the salt and then hash them to check whether the password and salt are correct. But then you're still stuck with trying all possible passwords until you find the correct one instead of using tables to speed up your brute force attack.

I agree then, encrypting the salt with the password doesn't provide any real benefit. But you won't be performing a separate attack on the salt and then the password, you'd just decrypt the salt with each possible password, hash it along with the password and see if that password matches the stored hash.

Re:They don't necessarily get the salt (1)

sgbett (739519) | more than 3 years ago | (#35149922)

The purpose of the salt is to stop people using pre-computed rainbow tables.

With a different salt per password (even known) they have to generate rainbow tables per salt/password.

If the salt is the password then you only need generate one rainbow table to crack the whole list.

Re:They don't necessarily get the salt (1)

PRMan (959735) | more than 3 years ago | (#35150020)

Yeah, I was wondering whether the GP was serious or trying to be funny. It's really hard to tell, because anyone that understands what salt is for will instantly see the humor in the suggestion. But since most people are cargo cult-ers when it comes to salt, I really could see someone thinking they were being extra clever.

Re:They don't necessarily get the salt (1)

sgbett (739519) | more than 3 years ago | (#35150142)

I was also wondering as I wrote the reply whether I was just being strung along. I thought it was better to take the hit and look a fool, even it stopped just one person actually doing this!

Re:They don't necessarily get the salt (0)

Anonymous Coward | more than 3 years ago | (#35150196)

How do you know which rainbow table to generate if you don't know the salt and only know the hash of the salt, and the salt was generated from a long random (non-wordt) string? You'd need to brute force the salt before you can generate a rainbow table, meaning you've just made rainbow tables impractical.

Separate out the Authenticaton (1)

qwertphobia (825473) | more than 3 years ago | (#35149716)

This wouldn't be an issue if AAA (authentication, authorization, accounting) was handled as a separate function.
Root access to the application server does not automatically become root access to the password database.
The password system should be approved/denied and not just a database of the hashes.

Check out Apple's Open Directory as a good example.

using game of life? (1)

Gunstick (312804) | more than 3 years ago | (#35149718)

What about using a cellular automate?
A silly idea I just had yesterday.
Take a grafical representation of the password, then "hash" it by running 100 generations of life through. Store the result as the hash.
The salt would be an additional life colony so that after 100 generations you're not going to end up with a dead colony.

Oh, I can't patent the idea, I'm not the first one thinking of that. http://kestas.kuliukas.com/GameOfLife/ [kuliukas.com]

Re:using game of life? (1)

vlm (69642) | more than 3 years ago | (#35149844)

What about using a cellular automate?
A silly idea I just had yesterday.
Take a grafical representation of the password, then "hash" it by running 100 generations of life through. Store the result as the hash.
The salt would be an additional life colony so that after 100 generations you're not going to end up with a dead colony.

Oh, I can't patent the idea, I'm not the first one thinking of that. http://kestas.kuliukas.com/GameOfLife/ [kuliukas.com]

GoL isn't as good of a hash compared to a more traditional hash. First thing that comes to mind is some hashes can spread a single bit change faster than GoL's "speed of light" limitation. The "c" limit in GoL is that a glider etc cannot move faster than a cell per generation in any direction, but I think there are hashes where a single bit change can spread across the hash faster than one adjacent bit per complete hash function. One generation of MD5 beats 50 generation of GoL on a 100x100 board in terms of smearing that single bit across the result.

Also you can get into huge arguments but generally running a hash multiple times doesn't spread the bits much better than running it once.

Iterated hashing... (1)

aaaaaaargh! (1150173) | more than 3 years ago | (#35149742)

I'm skeptical about schemes like PBKDF2. Doesn't the passphrase loose entropy each time you hash it? Instead, for iterated hashing it's probably better to use a one of the methods of transforming a conventional block cipher into a hash function. Anyway, what you should worry about is not so much the hashing itself but the entropy of the passphrase.

For example, I doubt many human-invented passphrases would stand a chance against a cleverly-generated, terabyte-sized dictionary. Heck, most people use "1234" anyway, don't they?

No kidding. (1)

Stumbles (602007) | more than 3 years ago | (#35149770)

That's about the most "Duh" article. Anyone with half a brain should know if they are already in all bets are off and it matters not a whit if you used corned beef to generate your hash.

Re:No kidding. (1)

wealthychef (584778) | more than 3 years ago | (#35149852)

That's about the most "Duh" article. Anyone with half a brain should know if they are already in all bets are off and it matters not a whit if you used corned beef to generate your hash.

Finally! Man I was starting to think I was reading the world's first Slashdot article to have nothing but honest discussion, without trolls, jokes, offtopics or idiots! You broke the spell.

the problem: hacker already has full control (0)

Anonymous Coward | more than 3 years ago | (#35149786)

>quality of your salt values doesn't really matter when an attacker has gained full control
That's true no matter what once the system is compromised! Salts are stored in clear text in the password file

No it isn't that relevant. (0)

Anonymous Coward | more than 3 years ago | (#35149792)

The function of the hash is to make it computationally infeasible to calculate back from the output what the input was, irrelevant of the actual input. The output is then unidirectionally linked from the input so only the correct password (with a chance of 1/(2^(bits in hash - 1))) can be used to log in. Salts serve to complicate pre-computed sniffing (since you cannot precompute what effect the salt would have on your hash) and comparison (since two identical passwords aren't the same hash). So, net result:

- It really doesn't matter where your salts come from. Even if it's just a counter, your passwords will all be hashed with a different salt and will be different. The attacker cannot just compare passwords and he'd have to recreate rainbow tables for each password yet again, making it 2^(bits in hash) per password, instead of 2^(bits in hash) one time.

- Hashes aren't so much made for speed as for the knee-point of sufficient diffusion versus high speed. Weaker hashes may be slightly quicker but are lots weaker, stronger hashes would be much slower but not much stronger. The bit length of properly designed hashes is indicative of their strength; if they cannot do that (as MD4 couldn't after scrutiny) its diffusion isn't sufficient.

So yes, SHA1 + salt is enough for your passwords if you have sufficiently many different salts and use it properly, and if 160 bits are enough for your data (or how many bits of actual diffusion result from its usage, I believe it'd been reduced slightly). If you need 512 bits of resistance (which you *most likely* don't) try Skein.

Re:No it isn't that relevant. (1)

makomk (752139) | more than 3 years ago | (#35149910)

Hashes aren't so much made for speed as for the knee-point of sufficient diffusion versus high speed.

Most common hashes are designed for speed, though - more specifically, they're designed to be fast to compute in software rather than just in hardware. As it happens, this is actually a good thing - it means a determined attacker can't get as much of a speed-up relative to the software implementation by constructing a hardware brute-forcer.

Are MD and SHA easily reversible? (4, Interesting)

Frogg (27033) | more than 3 years ago | (#35149798)

I don't get it - surely it shouldn't matter if someone gains access to the password verification routine, the salt and the encrypted passwords... unless the password hashing/encryption is easily reversible?

They've still got to try and brute force match the encrypted data with a dictionary attack - sure, having the salt makes it easier - but if you've got the salt and the encrypted passwords it doesn't matter what encryption algorithm is used, you've still got to use a brute force dictionary attack. Most encryption algorithms aren't easily reversible - and that's the whole point.

Re:Are MD and SHA easily reversible? (0)

Anonymous Coward | more than 3 years ago | (#35149900)

http://codahale.com/how-to-safely-store-a-password/

Re:Are MD and SHA easily reversible? (0)

Anonymous Coward | more than 3 years ago | (#35149986)

His point is that because the algorithms are fast, the brute force attack is feasible.

If you read the article, he specifically mentions* that with relatively modest hardware an attacker can brute force a "typical" password file in 33 days.

*Actually he says that you can cover the same ground as a typical rainbow table in 33 days, but the statements are close enough and I don't expect everyone to know what that means. What I stated is close enough for most purposes.

Re:Are MD and SHA easily reversible? (0)

Anonymous Coward | more than 3 years ago | (#35150026)

Encryption should never be used to protect a plaintext password, only a hash (ie, a "one-way" function).

Re:Are MD and SHA easily reversible? (0)

Anonymous Coward | more than 3 years ago | (#35150048)

The problem is that these general purpose hashes are so fast that brute forcing is relatively trivial.

Re:Are MD and SHA easily reversible? (0)

Anonymous Coward | more than 3 years ago | (#35150076)

Well, I the point of the article is that with a few GPU cards an attacker can brute force attack your hashed password set fairly handily, esp if you are using unsalted hashes. Salts help, but the power that an attacker can bring to the table (quite inexpensively) is on the verge of negating the advantages of a salt.

Basically statements like "Most encryption algorithms aren't easily reversible" are not quite true any more. No they aren't easily reversible, but it can be done relatively quickly regardless.

Re:Are MD and SHA easily reversible? (1)

djshaffer (595950) | more than 3 years ago | (#35150128)

Not only that, but when salt is done correctly you don't care if the attacker has the salt.

The steps:

* Salt every password with a different salt value.
* Store the salt with the hashes.
* If an attacker gets your user file he has to brute force each password separately, instead of using a rainbow table.

Re:Are MD and SHA easily reversible? (0)

Anonymous Coward | more than 3 years ago | (#35150178)

The whole point is that MD5/SHA* are _fast_. Why use a fast algorithm to encrypt/hash something that you don't need speed for? A fast algorithm just makes brute-forcing passwords faster.

Well, no, not really (0)

Anonymous Coward | more than 3 years ago | (#35149854)

As long as you use a different salt for every user, a potential hacker would only be able to hack one account at a time, even with access to your entire user table. That being said, using sha 512 would make this a very tedious task.

WPA uses sample principle - slow by design (1)

drop table user (1517433) | more than 3 years ago | (#35149930)

https://secure.wikimedia.org/wikipedia/en/wiki/Wi-Fi_Protected_Access#Security_.26_Insecurity_in_pre-shared_key_mode [wikimedia.org]

If ASCII characters are used, the 256 bit key is calculated by applying the PBKDF2 key derivation function to the passphrase, using the SSID as the salt and 4096 iterations of HMAC-SHA1.

Slow by design.

Here's an idea (1)

t3sser4ct (1522605) | more than 3 years ago | (#35149934)

I've always wanted to experiment with this, but I've never tried it. If you're using something open like PHP, recompile the binaries with your own modifications to the md5() algorithm (or whichever function you're using). It doesn't have to be anything significant, but changing a few constants or routines and/or hard-coding a salt would make it pretty much impossible for someone to successfully attack the hashes without first realizing your trick, getting access to the binary, and reversing it.

Isn't salting to avoid similarities in hashes? (1)

rsk (119464) | more than 3 years ago | (#35149936)

I'm fairly green when it comes to the security game, but wasn't the purpose of the salting to avoid the issue we saw with Gawker in that once you figured out Bob's unsalted password "password" hashed to "5f4dcc3b5aa765d61d8327deb882cf99" you suddenly has the credentials for X other users that all used "password" as their password as well? Where if the password had been salted all the hashes would be different and they would have had to brute force each one?

If the hacker has root access to your machine and has access to the encrypted passwords, salts and your code... it sort of seems like a given that you are (a) screwed and (b) they can brute-force the passwords with a much higher success rate.

I was thinking salting was just helpful when the passwords got exposed/stolen but the rest of the machine/code/etc. wasn't compromised. (not sure when that actually happens, but hey)

Okay...waitaminute.. (4, Insightful)

Chas (5144) | more than 3 years ago | (#35149978)

So you're saying SHA+a salt value sucks *IF THE ATTACKER ALREADY HAS ROOT ACCESS*?

Ore are you saying SHA+a salt value sucks *IF PEOPLE ARE USING WEAK DICTIONARY PASSWORDS*?

Can I get a "well fucking DUH!" here?

Seriously, exactly how tall are you claiming this molehill to be?

In BOTH cases the problem IS NOT the weakness of SHA+salt.

In the latter, the problem is some jackass used a crappy password. And even that's defensible if you have things like login restrictions and account locking in place.

In the former, well, not sure how to put this politely, THEY HAVE ROOTED YOUR BOX! At that point, you've got MUCH bigger problems on your hands than their ability to decrypt your password database.

Sorry, but this sounds like someone with SEVERE tunnel-vision here. They're so monofocused on "A" problem, that they fail to see the larger ramifications of the scenarios they construct.

Re:Okay...waitaminute.. (1)

Noam.of.Doom (934040) | more than 3 years ago | (#35150198)

I agree; isn't it like saying "thieves can rob your house if they manage to bypass your security systems"?

Desktop Supecomputers (1)

parlancex (1322105) | more than 3 years ago | (#35149998)

Desktop supercomputers (GPUs) are cheap nowadays. Modern GPUs can process over 3 billion (yes, billion, with a B, http://www.golubev.com/hashgpu.htm [golubev.com] ) SHA-1 hashes per second, and this is where good salt gains it's importance, because even a very strong password of completely random upper and lower case letters and symbols could be extracted from it's SHA-1 hash on just 3 or 4 GPUs in less than 24 hours. Good random salt can increase this search time immensely.

That said, good password practice is obviously to avoid re-using passwords for different services, and if people actually followed that in practice it wouldn't be such a big deal for an attacker to gain access to the password plaintext, because if they have the hash database they probably have already compromised the site / system anyway, and getting the passwords wouldn't help them get any further access to other systems.

gOODBoy (-1)

Anonymous Coward | more than 3 years ago | (#35150006)

cool bro... nice post...
visit my blog :
http://itsumonojinan.wordpress.com

Least of your worries (0)

Anonymous Coward | more than 3 years ago | (#35150014)

nd the quality of your salt values doesn't really matter when an attacker has gained full control, as happened with rootkit.com. When an attacker has root access, they will get your passwords, salt, and the code that you use to verify the passwords."

Um, yes. They will have the code you use to verify the passwords. Just like they would have the code for ANY authentication or any other security mechanism if they have this level of access. That problem is, by definition, not solvable.

Passwords should be considered deprecated (0)

Anonymous Coward | more than 3 years ago | (#35150060)

I don't understand why we are still debating this... It is the old debate of "is it ciphered enough so the enemy can't read it."
Well, the history proves that the enemy always ends into deciphering.

So protecting data or an access by a password is a weak process. First there is a piece of the key that is known by an individual.
Second it is an information stored somewhere on a disk or similar device.
Let's be clear, when an attacker has broken into your environment and the only thing left to protect you is an encrypted string. I am sorry but you are already screwed.

From my point of view encrypting some data will never be enough to protect them because it is a wider problem.
Now find something that you will be comfortable but protect it in the peripheral as well.

so? (1)

kikito (971480) | more than 3 years ago | (#35150088)

If an attacker has got root access, he can reset the passwords to whatever he wants. Unless I'm missing something, that's endgame. Users could have the passwords stored directly on the database, and it would make no difference.

Do you even know what hashing is? (0)

Anonymous Coward | more than 3 years ago | (#35150110)

> When an attacker has root access, they will get your passwords, salt, and the code that you use to verify the passwords.

Simply put: No.
They get your salt and your code, sure... but try to figure out what hashing is and why we use it before uttering such complete nonsense.

Of course salt matters (1)

DrXym (126579) | more than 3 years ago | (#35150120)

Without salt all duplicate passwords share the same hash. That's the first problem. So if 30000 of your users share the same password you've cut the amount of work the attacker has to do. Once they dictionary attack one password they have all 30000 because the hash is the same.

The greater benefit is that unless the attacker knows how the salt was created and applied (e.g. prepended / appended), you stop dictionary attacks dead in their tracks. e.g. my salted hash might be a hash of the registered email address + plaintext password + some secret string of a random nature.

That means that even if the attacker stole my database they would not be able to dictionary attack it unless they also had the secret key. So at a minimum the secret should not reside in the same db as the hashes. Better yet, the hasher should not reside in the same process as the login server, better yet it should be on a different, protected box with a well defined API.

Degrees of Ownage (1)

LaminatorX (410794) | more than 3 years ago | (#35150176)

"When an attacker has root access, they will get your passwords, salt, and the code that you use to verify the passwords."

While better password encryption is certainly a good thing, if your attacker has root access already, it's only a matter of time until he has the whole enchilada.

OTOH, you don't want rooting of one box quickly leading to compromise of a dozen others due to the amount of lazy password reuse that goes on.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?