5 ms·
Because the developer is storing passwords in plaintext, and he wants to save database space. This seem far fetched, not sure what thought process would lead a
by obiterdictum 14y ago
Because the developer is storing passwords in plaintext, and he wants to save database space.
This seem far fetched, not sure what thought process would lead anyone to come to this conclusion. Even if you have a million users, you have ~8MB worth of passwords. I'd imagine even developers who are not competent in cryptography realise that.
- bjourne 14y agoSome developers love that kind of micro optimizations. Even smart ones. I've had my varchar(256) columns changed to a more modest varchar(30) because I was "wasting space." Those people dont like being wrong either so there's no point arguing it either and instead concentrate on the bigger issues.
- btilly 14y agoI've seen that, but once the internal format is actually explained, varchar(256) generally survives. For those who don't know, for varchar(1) through varchar(256) the internal database representation in sensible databases is one byte to say how long the varchar is, followed by the actual data. There is therefore absolutely no difference between the representation of varchar(30) and varchar(256) - it is just an arbitrary restriction on what data is allowed to fit in there. But databases that support varchar(257) need 2 bytes in front for it.
- edanm 14y agoThanks for the explanation, didn't know that. Is this true in most modern DBs? (I'm thinking MySQL and Postgres particularly).
- icebraining 14y agoClose enough in PostgreSQL. String columns larger than 256 actually use 4 bytes to indicate the length, but on the other hand, large strings are automatically compressed, so they may use less space than 4 + length. http://www.postgresql.org/docs/9.2/static/datatype-character.html http://www.postgresql.org/docs/9.2/static/datatype-character...
- lucaspiller 14y agoI believe in InnoDB the way text and varchar(X) is stored is exactly the same. They both only use as much space as the data they are storing requires. However if you pass a 101 character string to a varchar(100) it will be truncated. I'd guess that is useful in some cases, but in reality you probably want to do the truncation in your application so you have more control over it.
- quesera 14y agoTruncation is the failure mode which MySQL describes as a feature. Don't use MySQL.
- ajanuary 14y agoI recently discovered its a similar case for numbers in Oracle, which slightly surprised me.
- derefr 14y agoIf you allow truly unlimited-length passwords, malicious users can set gigabyte-long passwords. Whether you hash them or just store them, that's a DoS waiting to happen with every login. So, there actually is a reasonable limit for the length of passwords, email addresses, and most other user-editable fields that end up either being hashed, or shoved through to the database. That limit is just probably somewhere around 100KB to 1MB, not "eight". ;) More importantly, that limit is an infrastructure concern, not a business-domain concern; it's best enforced by something like nginx spitting out a 400, not the model-validation logic in your app server.
- fruchtose 14y agoWhile this is true, hashes use a set number of characters. For example, SHA-256 hashes can be stored in 32-character hex strings. In that sense, there's no point in allowing for a variable length field for password hashes.
- vidarh 14y agoI would think that the kind of developer that considers it acceptable to store passwords in plaintext could easily be the kind of developer that would make arbitrary decisions based on feelings rather calculating the actual likely storage a longer limit would result in to make an informed decision...