Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

That's one attack vector. Assuming someone does attempt to use a brute force method, longer salts do matter. I think that qualifies as non-orthogonal to "crackability," even if orthogonal in some cases.

Truthfully, this isn't even worth talking about. If your user's passwords are compromised, you've already lost the security battle. Hopefully you weren't actually storing something important.



That's horribly irresponsible. Using your logic, you might as well just store the passwords in plaintext. Most people don't use different passwords for different applications, and your web application is inevitably going to expose all your users passwords, like every other web app that has been SQL-injectable (ie, almost all of them).


As a person interested in security, you're well-familiar with the fact that nothing is 100% secure. Choosing a less secure option over a more secure one is not tantamount to choosing no security at all.

That said, I personally don't mind plaintext passwords if there's a good usability story that goes along with it and if the security tradeoff is negligible. I put the odds of my user database being exposed at approximately zero, so generally it's a fine design decision. When was the last time you heard of passwords being stolen en masse from a major site that didn't also include a hard drive being stolen?


As a person who spends 3-4 days a week assessing other people's web apps, I'm well-familiar with the fact that it's a very good bet that everyone's web app is SQL-injectable, whether they've tried to stop that attack or not. For example, do you know how internationalization works?

I have no idea why you think the public is told every time a a password table is dumped. In fact, change that "every" to "any".

Here, let me make this easier for you: if you ever plan to monetize your application, you will fail PCI audits for doing a crappy job with password storage. But I'll do you one better and give you a tip from the trenches: if some lame PCI auditor sees that you don't know what you are doing, his company is going to roll you for 8 billable weeks, laughing at you the whole time, before they give you the meaningless stamp of approval that lets your process credit cards.


So where's the best-practices security checklist?

I'm not a security expert. I write webapps. I'm open to learning new techniques and using other people's libraries. However, I need to balance that against the need to get something out the door. As mynameishere put it, I'd love to have a website that's even worth breaking in to.

If there's some sort of tutorial out there that says "For passwords, use this library. For SQL injection, escape your parameters with this procedure. Here's how to secure your server from being rooted. Add these lines to your mailserver's config to avoid being used as a spam vector", I'd love to read it.


We take requests! I'm working on this with my partners. Thanks for the suggestion.


reddit was - although it was a hard drive stolen.




Consider applying for YC's Summer 2026 batch! Applications are open till May 4

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

Search: