▲ 1 points

Why is nobody interested in verifying their site's password storage?

by bozho·12y ago·2 comments·view on hn ↗

Two weeks ago I made a weekend project: http://www.saltedhashed.com/ and posted it to HN (twice) and reddit, and also blogged about it. But nobody seems interested.

Is it that:

- too much effort is (thought to be) required for validating ones site

- the incentive is not good enough

- it's not clear what it's about.

I'd like any feedback, so that I can improve the possibility of people showing off their good password storage algorithms.

2 comments

hey there,

I'm running elipsis.io which is basically an online password vault. I almost registered my app on your website but ended up not doing it. Here is why:

1) yes, creating an endpoint specific to your app is not something I am willing to do. Mostly because of the effort, also because I consider it bad practice. I'm not going to pollute my webapp for some 3rd party that is not core to my 'business'.

2) you're pretty much telling me to return an API that I need to protect against DDOS attacks. Yes, computing a salted hash is CPU expensive, as it should be, and I'm not going to make it easier to DDOS me. I have a whole bunch of higher priority items. Password salt verification is at the bottom of the list.

3) There is no incentive to use your service. I completely feel your pain there. You need a lot of users to know your service for third parties to register and use your brand. And you need these third parties to help your brand be known to the end users. Which come first ? The egg of the chicken ? I am sorry but I am not going to be the chicken...

4) I'm not going to tell the world how many iterations are used to generate hash based on my XXXbits key. Good security is only through transparency but there is no need to tell the number of hashing iterations. Users don't care. I just make sure it's as high as my hardware allows vs user's response time.

5) any website can lie to your service and be 'verified' as secure.

6) even if your service was worth it, there are many attack vectors that I am more worried about than just the password hashing. Password hashing is a no brainer if the standard solutions are implemented. Other stuff in-memory protection (make sure a plain text password is not in your redis), SSL, etc. are a bit more complicated.

Sorry, I'm not just buying the idea. I'm sure there are plenty of things that could be done to help people be better at security. Keep improving !

Your using stock bootstrap (which is fine) and targeting developers (which isn't) and mentioning words like password, secure and verified.. First impressions count