Live data from Hacker News

Hacker, Hack Thyself

blog.codinghorror.com

71–80 of 114 posts

Re: Hacker, Hack Thyself

#72

Earlier quoted context omitted.

Which they already do; from the post: > Users cannot use any password matching a blacklist of the 10,000 most commonly used passwords.

My question is, is 10k good enough? Wouldn't it be better to check against more? 50k?

the problem is once you get to 10+ char passwords the common password list gets really tiny

Re: Hacker, Hack Thyself

#73

I am not an expert on password hashing but I was wondering why can't the websites hash their passwords twice using two different hash algorithms. That way when the hashes are exposed, the attackers have to go through two algorithms. Is the time complexity increase only marginal that people don't do this ?

I'm not sure how modern hashes fare in this regard, but one issue is that hashing a hash reduces your input space from all possible passwords to all possible hashes of the first hasher.

Re: Hacker, Hack Thyself

#74
post #7

I saw a very interesting talk last year from someone who, as part of a company's security team, had set up a system that continually attacked the hashes of every employee's Active Directory passwords. If one was cracked, the employee would receive an automated email with a note containing the last few characters of their password and a suggestion to change it. I recall they also spoke on some security aspects of the…

checking against the most common password lists (with some masking, maybe?) achieves _most_ of this, but you'd definitely need to do an offline attack to do better than that, on the order of an hour or so of GPU time per account. It wouldn't be trivial!

Re: Hacker, Hack Thyself

#75
post #60

Earlier quoted context omitted.

I'm not sure why you think this article shows that with best practice passwords, it's a relatively weak control? From the article a user choosing a random (i.e. not in wordlists) 8 character password with upper/lower/numeric characters could expect an attacker to take 3 years to crack the password (and that's attacking one hash!) Now to be clear, I totally think that passwords are a bad idea (mainly because humans ar…

Quoth the article: A very motivated attacker, or one with a sophisticated set of wordlists and masks, could eventually recover 39 × 16 = 624 passwords, or about five percent of the total users. That's reasonable, but higher than I would like.

Sure so the attacker has entirely compromised the site in the first place, offline brute-force only works where the attacker has already got a copy of the database.

They've then eventually got access to 5% of the user's passwords, and the one's they got access to were all based on dictionary words...

Assuming that the site has any level of reactive/detective controls, they've noticed the breach and invalidated the passwords, thus rendering them useless.

What I'm saying is the offline password cracking times demonstrated in this article don't seem to indicate any more weakness in the use of passwords than was already known. the percentage of attackers who are going to bother with hitting a PBKDF2'ed password database on a forum site with any level of dedicated cracking past a run with some dictionaries, just isn't that high.

Attackers are drowning in existing compromised password databases already many/most of which exposed clear-text or weakly hashed (MD5/SHA-1 with no salt) passwords, so realistically speaking the incentives for getting another set where you really have to work hard to get them, isn't likely to be that high unless it's a high value site.

If you want examples just look at the lists on https://haveibeenpwned.com/ 500 million accounts with cleartext passwords from a single dump is at the top of the list.

That said, I admire discourses efforts to move the bar higher by increasing complexity and blocking weak passwords, all helps people move away from less secure alterntives

Re: Hacker, Hack Thyself

#76

Earlier quoted context omitted.

You are correct. It is a mistake. It's also confusing naming, because not too long ago, nVidia named their cards with GT and GTX as a suffix, such as the GeForce 8800/9800 GT and GTX.

Once they run out of numbers again maybe they'll turn it into an infix? Looking forward to the Nvidia 48GTX70!

pshh, that's nothing compared to the circumfixed Nvidia GT5790X

Re: Hacker, Hack Thyself

#78

I am not an expert on password hashing but I was wondering why can't the websites hash their passwords twice using two different hash algorithms. That way when the hashes are exposed, the attackers have to go through two algorithms. Is the time complexity increase only marginal that people don't do this ?

There's no actual need for two algorithms -- you can just hash them with the same algorithm twice. This is essentially what PBKDF2 does, hashing the password a configurable number (thousands) of times. It's a little more complicated than that, but that's why you should not just use a hash, but a KDF like PBKDF, scrypt, bcrypt -- they'll do what you're suggesting and more. They are exactly designed to make it a bunch of work for an attacker to guess-and-check your passwords.

Re: Hacker, Hack Thyself

#79

Most of those passwords that got cracked, my reaction is, OK, of course that's a weak password... but "1qaz2wsx3e" and "A3eilm2s2y"? Geez! How'd they get those?

> 1qaz2wsx3e

That's just diagonals on the QWERTY keyboard.

> A3eilm2s2y

Apparently that's an in-game password for https://en.wikipedia.org/wiki/Parasite_Eve_II

Commonly used passwords can be pre-hashed and easily cracked.

Re: Hacker, Hack Thyself

#80

Encrypting the hashes in the database would make it safer. That way the password hashes can't be attacked in this way unless they can decrypt them first.

Encrypting passwords wouldn't add a lot here unless you're using some mechanism to protect the encryption/decryption key (like using a Hardware Security Module), as an attacker who compromises the database is likely to compromise the key at the same time. If you do have a hardware security module, then why not just do away with hashing altogether, encrypt the passwords with AES-128 and you'll likely be fine (as long…

It's slightly useful if you only give the key to your application servers, and not your database servers. Now you need an application server breach and not just read access to a database.

It's not unheard of for something like a decommissioned database backup to wind up insecure and on the internet without being properly wiped, causing a whole-db leak without anyone actually breaking into a production system.

Not sure it's worth the effort:reward though

Post reply on HN