Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 4 Sep 2016 12:00:18 -0500
From: "Denny O'Breham" <obreham@...il.com>
To: passwords@...ts.openwall.com
Subject: Re: Authentication process

Yoha - I read your 2016/08/25/1 email and we are on the same page.

Let me state the problems I'm trying to solve through personal experiences:

1- As a user, I hate choosing passwords.  I try to deal with all the rules
each site gives me and I end up with passwords I can't remember. I find the
process very frustrating.  Frustration is not good for UX.

Lately, a hobby forum I'm registered to was hacked into (the admin is
actually a big company having several forums).  The result was a mandatory
password change, with a new set of rules ridiculously severe and a 90 day
expiration date.  Just to show you how much frustration there was, some
users were logged in for so long (w/ cookie) that their email weren't even
valid anymore and couldn't be reach by the admin.  I don't remember the
password I have (I would have to sign in with 'Forgot password?') and the
password I thought was well crafted could probably be guessed by an expert
in the time I take to blink.

The answer to this, as someone mentioned, is a password manager.  Good
idea, although I have difficulties using programs I don't know how they
work and how they store my data (even worst when I don't know where they
store it).  Which one do I trust?  Will the program still be available in a
few years? Will I be able to change browsers and recuperate/transfer my
passwords?  Personally, I sometimes use different browsers, having them
synchronize is worst than synchronizing machines.

2- As a website owner, I would want to protect my database.  But one major
deterrent for an attacker is knowing that every single user has used a
hard-to-guess, unique, password, which is out of my control.  By enforcing
a password policy, I frustrate my users and it doesn't change much to the
attacker;  At best, it will create a new set of rules for future attackers
(which they will probably take as a challenge).

Again, forcing everyone to use a password manager could solve the problem,
but it's out of the control of the site admin.

So I'm not trying to solve problems such as eavesdropping or
man-in-the-middle attacks which are still possible at this time.  Even if I
wanted, I don't have the cryptographic knowledge for this.

It's really about database security and better UX.

My solution is the following:

When the user creates an account, I choose the password for him, let's say
it is "64hex" (It is actually a 64-character hexadecimal number).  I do the
usual one-way hash and store it in the server's database.

Then I create another random password - let's say "64hex2" - and save it in
clear in the server's database next to the hashed "64hex" and the username.

Then I ask a password from the user.  There could be some simple rules,
such as minimum length, but let say there is none and that the user choose
the password "p" ( "123456" is too difficult to remember :) ) and that this
is the password he used on all his favorite websites.

Then I combined the user's password with "64hex2" which gives "p64hex2",
i.e. a very strong password no matter what.  I use this password to encrypt
"64hex" and send the result (which I call the 'code') to the user.

"64hex" is now securely kept on the user's storage space.  To open it, both
the user's password and the server's password are needed.  From the point
of view of the website owner, I responsibly encrypted the code, not relying
on a maybe weak user password, i.e. no liabilities.

I also create a personal URI, i.e. one that goes to the login page, with
the code into the query (If you used the program in github, you'll notice
that the query is not stored in your browser history, thanks to a
redirect).  This way, the user only needs to enter his username & password
into the login page, as usual.  I also plan on sending a html file with the
code, that has an automatic (javascript) redirect to the personal URI.  One
click on the file and the login page opens in your favorite browser.  If
the file is in the cloud, you get access from any of your machine easily.

Say an attacker has access to the code (or even the personal URI).  Then we
are at a security level identical to what we are used to right now, i.e.
the attacker has to go on the website (to have access to "64hex2") and
guess "p" and he's in.  Without access to the server, he can't guess
"p64hex2".  But for this to happen, he needs to have access to the user's
storage space (machine or cloud) or intercept the communication (which is
still a possibility with traditional login).

Say an attacker steals the database.  "64hex2" is useless without the
user's code and not only hashed "64hex"s are unguessable, but they are
useless to the attacker as these passwords are unique to this site only.

Say, as a site admin, I'm afraid someone has breached into my database (not
even sure it is still a problem now, password-wise) and I want to reset all
passwords.  So I do and change "64hex" to "64hexA" and "64hex2" to
"64hex2A", create a dummy user password "p2" and send the new code to the
user.  If I don't give "p2" to the user, he won't even be able to log in.
But he will be able to reset the password again - leading to "64hexB" and
"64hex2B" and a new code - with his password "p".  Therefore the user can
still keep his password while my database is totally renewed in a matter of
minutes, if not seconds.

Same thing if the user suspects that his code was stolen.  He asks for a
new code while keeping his password "p",  he replaces his old html file
(with the personal URI) with the new one and he can get back to his old
habits.

What do you think?

Content of type "text/html" skipped

Powered by blists - more mailing lists

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ