[lug] Application Password Security

[Dan Ferris]

Don't store plain text passwords for a history.  Just store each salt
and hash in your database with a date stamp and if you're going to force
them to change, you just query for the most recent N hashes and you can
check each one to see if the password is being reused.  When you do
auth, you just use the most recent hash and salt.  Don't forget to use a
constant time comparison of your hashes.

That being said, forcing users to change passwords on web apps is a
waste.  Users will completely hate it and if they're savvy enough to use
something like Keepass with long passwords (I use 50+ characters if
possible) they will really hate it.  If it's an internal app, I wouldn't
even bother with passwords, you should use whatever central auth
database already exists (Active Directory, LDAP, Kerberos, etc).

If you're really paranoid, you can integrate with Google authenticator /
TOTP for a second factor.  TOTP is actually extremely easy and you can
use any medium you want to share codes it doesn't have to be Google
Authenticator.  You can use SMS, Email, etc.  I have a python script I
use as a backup to Google Authenticator and it was 9 lines of code
(using the onetimepass library).

Dan

On 06/20/2016 01:44 PM, George Sexton wrote:
> I'm writing a password security update for some software. I'm going to a
> BCrypt algorithm which uses a salt, and an iteration count to transform
> the password. I would go to Argon2, but I'm just not seeing a Java
> implementation yet.
> 
> The software has historically had a feature that stops users from
> re-using passwords by keeping a history. If the password database is
> compromised, along with the password history, then I'm potentially
> serving up not only their current password, but historical ones as well.
> 
> The question I'm struggling with is what's the bigger security risk?
> Users re-using passwords, or my app keeping historical passwords.
> Although I'm making it pretty expensive to generate a dictionary, it
> still won't be impossible. I guess where I'm ending up is that the
> chance of BCrypt password being compromised is lower than the risk of a
> user cycling through the same (or small set) of passwords.
> 
> I would be interested in hearing what others think...
> 
> -- 
> George Sexton
> *MH Software, Inc.*
> Voice: 303 438 9585
> http://www.connectdaily.com
> 
> 
> _______________________________________________
> Web Page:  http://lug.boulder.co.us
> Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug
> Join us on IRC: irc.hackingsociety.org port=6667 channel=#hackingsociety
>