3 ms·
I know, right? And even more insane, they only allow alpha numerics, no symbols allowed. And for probably the only password which matters...
by harshpotatoes 16y ago
I know, right? And even more insane, they only allow alpha numerics, no symbols allowed. And for probably the only password which matters...
- glhaynes 16y agoYes, exactly. I was surprised how little correlation there was between how important the security of the site was and what quality of password was allowed by the site.
- count 16y agoSome of that is archaic database tables (or using NIS/YP as the user manager in the backend). You didn't used to be able to start a password on AMEX's sites with a digit...
- Sephr 16y agoExcept that they should be storing the hash anyways.
- count 16y agoWhat part of archaic was clear? rpc.yppaswd isn't gone...
- drinian 16y agoNo bank should be storing passwords as plaintext, therefore the content of your password should not be their concern.
- bmastenbrook 16y agoI don't think it's just about hashing. When I see restrictions on passwords or other fields, I always assume the worst. If < is not allowed, that's because your password will show up unencoded in HTML somewhere. If $ is not allowed, that's because somebody is afraid that it will actually be treated as a variable reference somewhere. Likewise & or % in URL-encoded data, ' or " in JavaScript, etc. The most universal and silent restriction seems to be on NUL bytes.
- count 16y agoBack-ended by non-RDBMS systems, the banks may be using something like YP or NIS to store passwords so that multiple systems can hit one, central authentication system. NIS had horrible password restriction issues (much like LANMAN).