Hacker News new | past | comments | ask | show | jobs | submit login

When data leak occurs, nobody's going to brute force random passwords. They'll use dictionary attacks. Using SHA-256 is strange. Some websites store clear text passwords. Some websites store bcrypt hashes. Why do you focus on SHA-256? Is there some kind of statistics that this particular kind of hash is common among hacked websites?

I agree that it depends on attack scenario. My scenario is: I expect website owners to find out about attack in a timely manner and disable all compromised accounts. Of course I won't reuse single password across different websites. Also I feel that most important websites nowadays require SMS or E-mail factor when logging in from another device, so this further decreases requirements for strong password.

And, of course, I don't expect to be targeted by government. They'll just hit my head with wrench until I unlock my iPhone, that would be cheapest attack on me, independent on password length.




> When data leak occurs, nobody's going to brute force random passwords.

People will absolutely bruteforce random passwords. There are entire communities (like hashmob net, not sure if I am allowed to link it directly) devoted to cracking as many hashes of breaches as possible. Dictionary attacks will get you most of the easy passwords, but are quickly exhausted.

> Why do you focus on SHA-256?

I chose this hash because, thanks to Bitcoin, we know how fast specialized hardware to compute that hash can be.

> Is there some kind of statistics that this particular kind of hash is common among hacked websites?

It's not the most common. That would sadly be MD5. But SHA-256 is not rare either.

> They'll just hit my head with wrench until I unlock my iPhone, that would be cheapest attack on me, independent on password length.

I agree, rubber-hose cryptanalysis can be very cost-efficient. https://en.wikipedia.org/wiki/Rubber-hose_cryptanalysis Fortunately, many governments are opposed to this kind of cryptanalysis, but YMMV.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: