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

That's not quite the claim he made though. His claim is that the only reason to have those policies is to mitigate SQL injection and because you're storing cleartext passwords.

If you're storing password hashes, you don't care about the charset used for the password, and the only limitation on password length would be sane bandwidth concerns - who really cares if I send you 2 or 3Kb of password if your hash algorthm is going to store that in the same sized database column as "password123"?

Either they have those policies for a reason - they've got bad password storage practices, or they have them for no good reason - which is a very good excuse to ask "WTF?"

And do you _really_ think this might have "cut down on widespread security outbreaks"? That's a pretty lame justification in my opinion - it's like claiming I'd be "improving my users security" by disallowing vowels in passwords, to minimise the risk that they re-use existing passwords. There is no way to "enforce a unique password" without keeping too much knowledge of users passwords.

I think the OP's stated "concerns" are very valid, and I agree with him that Rackspace's policies and answers fall a long way short of providing the reassurance that they're storing critical security credentials in a safe fashion.




Be careful with that. BCrypt for example silently truncates long passwords (>72 chars).




Consider applying for YC's W25 batch! Applications are open till Nov 12.

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

Search: