This question already has answers here:
Closed 12 years ago.
Possible Duplicate:
What's the recommended hashing algorithm to use for stored passwords?
Hello, I've recently been told that common hash functions such as SHA256 are insecure for use as a password hashing function because they are "designed to be fast"(incidentally I asked earlier for faster hashing functions over at programmers.se). So my question, what should be used for websites or other general applications?
Also, secondary question: Is SHA256 really not a good choice for hashing passwords? I kind of don't believe it, but I've heard crazier things be true.
(note: assume all other proper actions are being taken such as unique salts)
You should use bcrypt.
At the time of writing SHA256 is adequate for password protection, though it may not be in a year or so.
I'd maybe use SHA512 as I'm not too well traversed in what is really secure at the moment, and I'm not sure if anything can be really secure, with the huge increases of computing power in CPU's and GPU's.
Mike Howard's answer on the question Mark linked to is the correct best practice.
Simply using a good hash is insufficient because:
it does not protect you from rainbow table attacks. The same password will hash to the same result, every time. An attacker can compromise on the time vs. space tradeoff, pre-compute the most popular passwords and simply look up the answer. To defeat, you need to add a salt. (Mike suggests user id)
as you suggest, hashing algorithms are designed to be fast. This is sometimes desired, (such as getting the hash of a 50MB file) but in the case of passwords it not. Use a password-based key derivation function instead. It will significantly slow down an attacker, but not impact your own speed.
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 8 years ago.
Improve this question
I am trying to penetration test one of my websites.Username and Password is unknown to me.I am trying to break username and password using brute force attack.
Although,This strategy should be straight as I need to keep generating a new alphanumeric combination of variable length each time and posting it using some self written program.
But this strategy needs a lots of processing time and power. My Simple doubt is that is this strategy good enough for username and password breaking or some other task is expected to be done.
I have heard a lot about dictionary attack,But that too requires a predefined and pre-expected lists of usernames and passwords.
Should I go for brutus(but it didn't worked for me) or a self written program?
What is the right way of enlisting the username and passwords?
Online brute-force attacks against a live system are not viable as it’s simply too slow: limited bandwidth, latency, throttling, perhaps Captchas, etc. One could try a dictionary attack, but probably only with a very short list of passwords.
But for offline password attacks, where the attacker is in possession of the password hash, the only limiting factor is the hardware and software of his own system. However, often brute-force attacks are still viable only against high-value targets due to cost-benefit ratio.
Not only is it achievable, with modern approaches using GPUs and FPGAs, it's an incredibly viable approach. Note this doesn't necessarily apply to client-server models. However, if you have encrypted data protected by something such as PBKDF2, it is possible with enough computing power that the password and therefore key could be recovered. The appropriate approach depends on what it is you're trying to attack. Attacking websites is much more difficult as without a distributed attack the site can simple throttle its responses, slowing your attack time.
I've been researching bcrypt hashing, and of course one of the large benefits of the scheme its "adaptiveness". However, how is it anymore adaptive than simply increasing the amount of iterations you make over a SHA-1 hash? Say, instead of SHA-1 hashing a value 1000 times, you increase it to 10,000 iterations. Isn't this achieving the same goal? What makes bcrypt more adaptive?
Making many iterations with a hash function has a few subtleties, because there must be some kind of "salting" involved, and because existing hash functions are not as "random" as what could be hoped for; so care must be taken, in which case you end up with PBKDF2. PBKDF2 was designed for key derivation, which is not exactly the same than password hashing, but it turned out to be quite good at it too.
bcrypt has a (slight) advantage over PBKDF2-with-SHA-1 in that bcrypt is derived from the Blowfish block cipher. The point of having many iterations is to make the password processing slow, and, in particular, slow for the attacker. We tolerate that the function is made slow for the normal, honest systems, because it thwarts extensive password guessing. But an attacker may use hardware which the normal system does not use, e.g. a programmable GPU, which gives quite a boost to computations which fit well on that kind of hardware. Blowfish and bcrypt use RAM-based lookup tables (tables which are modified during the processing); such tables are easy to handle for a general purpose CPU, but quite cumbersome on a GPU; thus, bcrypt somewhat hinders processing enhancement by the attacker with GPU. That's a bonus which makes bcrypt a bit more desirable for a password storage than PBKDF2.
An alternative to both is scrypt. Unlike bcrypt, it doesn't make use of the somewhat unusual blowfish cipher, instead using any standard hash function, and it's specifically designed to be difficult to implement on dedicated hardware, by being both memory- and time-inefficient.
Your alternative is a bit underspecified. You didn't say how you combine password and salt into your hashing scheme. Doing this in the wrong way might lead to vulnerabilities. The advantage of bcrypt(and other standard KDFs) is that this is well specified.
If you look at PBKDF2 in the common HMAC-SHA1 mode it's very simililar to what you suggest.
That's essentially it. You can iterate any hash function. Some hash functions are better than other, so choose carefully.
MD5 for example is considered broken these days, and belongs to a category of hash functions which suffer from certain prefix-based attacks and birthday attacks.
bcrypt is a good rule-of-thumb because it gets a few things right (like salt) that you would have to explicitly implement if you used another function.
As noted in another answer the mechanism of iterating a hash function is very important, because it can unexpectedly weaken the algorithm or still fail to prevent some time-memory tradeoff attacks.
This is why PBKDF2 is your friend. It's detailed in RFC 2898. PBKDF2 is also future-proof because it doesn't depend on a specific hash algorithm. For example, can swap out MD5 for SHA3 when SHA3 is finalized by NIST.
Also, a slight catch on future-proofness. Bcrypt will work as long as the passphrase you're protecting is "between 8 and 56 characters." An important catch to keep in mind should your future ever require longer passphrases for some reason.
I believe the "adaptiveness" has nothing to do with the actual encryption but instead that bcrypt is an adaptive hash: over time it can be made slower and slower so it remains resistant to specific brute-force search attacks against the hash and the salt.
(Partly quoted from http://en.wikipedia.org/wiki/Bcrypt)
I'm bringing this up after spending a few hours trawling through a number of posts on SO with regards to the most secure way to handle passwords in PHP/MySQL. Most answers seem to be fairly out of date, as are links that people are directed to. Many recommend md5 and sha-1.
We all know that MD5 and SHA-1 are no longer worth using due to the fact that they have been reversed, and also because there are a number of databases out there that have built up millions of md5/sha1 strings. Now, obviously you get around this with salt, which I intend to do.
I have however recently started playing around with whirlpool, which seems much more secure, and up to date. Would I be right in thinking whirlpool+salt is ample protection for passwords?
I was actually considering something like this:
<?php
$static_salt = 'some_static_salt_string_hard_coded';
$password = 'some_password_here';
$salt = 'unique_salt_generated_here';
$encoded = hash('whirlpool', $static_salt.$password.$salt);
?>
What do you think? Overkill or sensible?
This is probably good enough for most applications.
However, salts become (almost) useless if your DB is leaked -- including the static one if your configuration file is leaked too. They are a good protection against rainbow tables, but nowadays it's easier to use a bunch of GPUs to brute-force a given hash.
IMHO, currently the best solution is to use bcrypt. It's apparently supported in PHP 5.3+, and here's an example of how to use it.
This will be enough (however, there is no sense in static hardcoded salt). And, why not to use SHA256? Whirlpool is rarely used.
It's particularly meaningless to discuss the merits of particular algorithms without a much wider consideration of the threat models and specifics of implementations.
Yes, whirlpool does appear to have some advantages in terms of how effective it is as a hash, but as Nickolay says that may be deceptive and due to the fact it is less widely used. But there are other considerations too - for some purposes storing a 128 character string for each account may be an unnecessary overhead. For everyone it's a question of what the software supports (and some people might want to use the same account record to control access to different systems).
At the end of the day, it doesn't matter how sophisticated your hashing algorithm is:
given a free choice, users pick bad, guessable passwords
users will use the same password for different services
If it works for you - then great - but there is no universal solution.
I was thinking about using 2 keys for hashing each user password, obtaining 2 different hashes. This way, it would be (almost?) impossible to find a password that works, other than the actual password.
Is that right? Is it worth it?
An important rule to learn is "never try to invent your own cryptography". You are just wasting time at best and introducing security holes at worst.
If you are unsure whether you are an exception to this rule, then you are not an exception to this rule.
The designers of cryptographic hashes already worried about collisions so you do not have to. Just pick one (SHA-256 is a fine choice) and focus your efforts on the rest of your application.
You might use SHA256 as a hashing algorithm instead. No collisions were found to date, and it's highly unlikely to see any collisions on passwords in the future.
You could just use a longer hash. SHA-512, for example, is 512 bits, and (assuming it's uniform) far, far less likely to clash as SHA-256. But personally, I wouldn't worry about it. Most passwords themselves are less than 32 bytes (256 bits), and so should have an extremely low probability of clashing with SHA-256.
I am a bit of a newbie around Security nitty gritties and especially around Cryptography.
In the application we are building(ASP.net application built on .NET 3.5), we are currently using Databases to save our users authentication information (AD etc is not an option at this point).
The intention is to do a one way salted hash of the passwords using SHA256Managed on user creation and then validate the users using the same.
Ideally, we do not want to use any third party dll's for the hashing algorithm unless absolutely necessary to avoid any unnecessary dependencies.
Questions:-
1. Is there a better option than doing a salted one way hash?
2. Is SHA256 a reasonably reliable / secure option or should we be considering anything else?
3. Is the SHA256Managed implementation in System.Cryptography good enough in terms of it speed etc or should we be considering 3rd party alternatives to it?
Any pointers as to the approach / implementation will be helpful.
I did some research on this back in the day, and the consensus was BCrypt was one of the best ways to do a one way hash.
You can see a C# implementation here: http://derekslager.com/blog/posts/2007/10/bcrypt-dotnet-strong-password-hashing-for-dotnet-and-mono.ashx
In addition, what's nice about BCrypt is you can decide how many rounds you'd like it to go through.
So, you can make it take about 1 second to encrypt for example. For a user, that's an acceptable wait time, but for someone trying to attack you through brute force, 1 second is an eternity.
I am no security expert, so take what I say here as a grain of salt. A salt you can send in to your BCrypt method :)
In addition, here's some advice from Atwood on this: http://www.codinghorror.com/blog/2007/09/youre-probably-storing-passwords-incorrectly.html
Update:
Since answering this, NuGet has made using BCrypt much easier: http://nuget.org/packages?q=bcrypt
I can't vouch for any particular implementation there, so take a look at the code, but this should make using and integrating BCrypt much easier.
Yes, retina scan (just kidding). Storing passwords as hashes with salt is the correct way.
SHA256 is good. Obviously I don't know the type of an application you are working on, but SHA256 is good for the vast majority of projects. You can always go to a higher key length (384, 512) if required. Consult with your security architect.
SHA256Managed (we are talking .net, right?) is good. We use it in our projects.
Please also consider reading this:
http://www.obviex.com/samples/hash.aspx
Yes, there's nothing wrong with SHA256 and certainly SHA256Managed will be "fast enough" for most use cases (I'm sure you're not expecting to be validating 1000s of login requests per second, and even if you were, the rest of the site would still be dwarfing the login requests...)
But have you considered the Membership stuff that's built-in to the framework? They're already done all the hard work in terms of securely storing credentials, and implementing all the support functionality as well (such as password resets, etc)
Storing password hashes with salt it correct. However, it's easy to get even that much wrong. Sure, right now SHA256 will keep the baddies at bay, but give it a few years. Suddenly, SHA256 might not seem so secure anymore. You need to use BCrypt, a future-proof hashing algorithm.
Problem with doing just one pass of SHA256 is it is too fast and one with great hardware can generate rainbow tables for lots of salts easily...to get around this you need to perform key stretching....kI'm not going to give you a lesson on key stretching but the bcrypt implementation that people talk about performs key stretching. If you want a more modern alternative to bcrypt which uses HMACSHA256 or 512 in .NET, I recomend this API:
https://sourceforge.net/projects/pwdtknet/