3 ms·
User management is not so trivial that the repercussions of doing it wrong are trivial (exactly as we're seeing now). Someone with a bit of experience in this
by sk5t 14y ago
User management is not so trivial that the repercussions of doing it wrong are trivial (exactly as we're seeing now).
Someone with a bit of experience in this field would know to include the hash algorithm in the stored data when processing a password set/change/reset. For example, good old Netscape LDAP server stored passwords in the general form "{ssha}xxxxxx", "{crypt}xxxxxx", or "{plain}xxxxx". This allows for easy comparison as users login, as well as for gradual upgrade to stronger algorithms in the future when accepting changes--one could extend with with "{bcrypt}", "{pbkdf2-10k}", etc., etc.
Having only a small number of trusted ignoramuses working on the code is a pretty lame defense. Honestly this stuff is in the news all the time. How could nobody at such a massive site raise the question, "if our database is compromised, will we be exposed as careless oafs?"
- rmrfrmrf 14y agoI agree with you completely. I was hoping people would take my comment more as important lessons than excuses. 1) Always review the code for sensitive data before allowing it to go live (especially by someone well-versed in security). 2) Have a plan of attack in place for security upgrades so that they're not quite so painful. 3) Despite day-to-day responsibilities, there need to be regular reviews of security practices by management.