I’ve been a proponent of the ASP.NET membership provider for a number of reasons:
HASHCAT SPEED WORDS PERSECOND PASSWORD
Or alternatively, you take a list of common passwords in a password “dictionary” and you’re going to have a similar result. In fact you only need to take a highly constrained range (such as 6 to 8 character lowercase) and you’re going to cover a significant number of passwords. What this means is that in the scale of potential passwords – that is using all the characters available and making them as long and as unique as desired – passwords conform to very, very predictable patterns. Only 1% of them contained a non-alphanumeric character.67% were reused by the same person on a totally unrelated service (Gawker).36% were found in a common password dictionary.45% were comprised entirely of lowercase characters.93% were between 6 and 10 characters long.When I analysed one of the Sony breaches last year, I found a number of pretty shoddy practices: A quick password practices recapįirst things first – we suck at choosing passwords. If they match, then I’ve just discovered the plain text password. I’m literally talking about taking a plain text string, hashing it then comparing it to a password already in storage. In this case when I say “break” or “crack”, I’m talking about re-computing hashes rather than finding weaknesses in the algorithms themselves.
None of this is about being “unhackable” it’s about making the difficulty of doing so not worth the effort. The trick is to ensure the effort to “break” the hashing exceeds the value that the perpetrators will gain by doing so.
And remember, a large percentage of these credentials will be reused across other services so secure storage is about protecting a lot more than just the site that was breached. So this is really the whole point of hashing – once you get owned to the extent that WHMCS and LinkedIn were, secure cryptographic storage of the passwords is the only thing saving your customer’s credentials. Disclosure of passwords in storage happens. It was a similar story with LinkedIn just a little bit later when 6 million passwords were exposed through (as yet) unknown or undisclosed means. In this case it appears that some basic social engineering was used to circumvent the host’s security thus allowing access to the database of user accounts. We were reminded of this just the other day when WHMCS was breached and thousands of account details were leaked. Now of course all the good upstream security practices such as mitigating against SQL injection vulnerabilities and protecting your backups still apply, this is about what happens once things go really, really wrong. The problem that cryptographic storage of passwords is trying to address is to limit the potential damage of unintended disclosure of passwords in storage. Let’s take a quick step back before talking about what’s wrong with the hashing algorithms of today. Worst of all, it’s leaving our hashed passwords vulnerable to the point that many existing accepted practices make salting and hashing next to useless.
HASHCAT SPEED WORDS PERSECOND MANUAL
Of course Moore’s law in itself is not new, it’s just that it has been effected on computer processing power to the point that what was once a very computationally high bar – the manual computing of vast numbers of hashes – is now rapidly becoming a very low bar. Suddenly, those nice tables of hashes for passwords of common structure became useless because the salted hash was entirely uncommon.īut now there’s an all new threat which has turned the tables on the salted hash – Moore’s law. Adding random bytes to the password before it was hashed introduced unpredictability which was the kryptonite to the rainbow table’s use of pre-computed hashes. So we started seasoning our passwords with salt. Suddenly, huge collections of passwords could be hashed and stored in these colourful little tables then compared to existing hashed passwords (often breached from other people’s databases) at an amazing rate of knots thus disclosing the original plain text version. Then along came those pesky rainbow tables. The one-directional nature of the hash meant that once passed through a hashing algorithm the stored password could only be validated by hashing another password (usually provided at logon) and comparing them. In the beginning, there was password hashing and all was good.
0 kommentar(er)
