Secure those passwords!

Stories about hacked or stolen password files keep coming. One of the most recent is a breech at IEEE.org – where 100,000 plaintext passwords were stolen a few weeks ago. The IEEE confirmed it a couple of days ago:

IEEE Statement on Security Incident

25 September 2012 — IEEE has become aware of an incident regarding inadvertent access to unencrypted log files containing user IDs and passwords. We have conducted a thorough investigation and the issue has been addressed and resolved. We are in the process of notifying those who may have been affected.

IEEE takes safeguarding the private information of our members and customers very seriously. We regret the occurrence of this incident and any inconvenience it may have caused.

There are two underlying problems. One we can address. One we can’t.

The problem we need to address is that programmers are sloppy. The application calls for having some sort of login with user names and passwords. So what do programmers do? They store the username and passwords as plain text in some sort of lookup table. They store the password lookup table in a volume where it can be accessed over the Internet.

The fixes are simple.

1. No plain-text storage systems – ever! Encrypt. Hash. Rinse. Repeat.

2. Don’t store the lookup table anywhere where it can be accessed remotely.

3. Don’t record passwords in log files.

4. Forget rules 1, 2 and 3. Instead, don’t let your programmers roll their own identity management system. If one needs to be built, make it a separate project and subject it to serious design work, security auditing and penetration testing.

No matter how trivial the “at risk” data, don’t create a lame login system. Ever. If a login/password system is required, take it seriously from a design perspective. It’s an attack surface!

That brings us to the second problem, the one we can’t address. Humans tend to reuse their passwords. They might have the same username and login in every e-commerce site. You’ve cracked one, you’ve cracked them all. And you know, that same login/password might also be their email access code, their remote network admin login/password, and their corporate portal login/password.

If your system uses an email address as the login, perhaps you’ve made life easier for your end users. You’ve also made it much easier for hackers to target your system, and for them to exploit a stolen login/password list from another site. If email hidden; JavaScript is required uses a password of DontGuessMe123 on one site, he’s probably using it on your site too.

Practically speaking, there’s nothing we can do about password reuse. But we can, we must, make sure that our own identity management systems are secure. If the IEEE can fail, we can too.

Z Trek Copyright (c) Alan Zeichick