Re: Securing Password Inputs

I would rather:

 <input type="password" pass-check-algorithm="blah"
pass-check-field="somefield">
<span id="somefield"></span>

As a feature of complaint browsers, then, as I type, they evaluate the
strength of the password using the pass-check-algorithm, and put a score in
<span id="somefield"><span>  I can then script around that, style as I see
fit, etc.

I've become convinced that this problem is an end-user problem, not
server-side problem. The real-time, as you type password checkers are
fantastic for shaming people in to making better passwords.  The only
problem I have is with the specific algorithms I come across.  Some just
want a capital letter + funky character, but 8 characters is enough.  But,
then, a password that is 50 characters long and all lowercase is 'weak'.
xkcd disagrees with that!!

So in the context of HTML5, you can defer the problem of 'how the check is
determined' by making the algorithm specifiable in an attribute.  Heck,
maybe even it's just a javascript routine.

Seth

On Tue, Aug 28, 2012 at 5:00 PM, Thomas A. Fine
<fine@head.cfa.harvard.edu>wrote:

> Hi,
>
> The primary problem is that you've accomplished nothing.  When the user
> enters "bob" and the server stores "**9f9d51bc70ef21ca5c14f307980a29**d8",
> this  simply becomes the new magic string that will allow login.  A hacker
> interested in reusing passwords has what they need from raiding the
> password database without knowing or caring that it used to be "bob".  They
> can just use "**9f9d51bc70ef21ca5c14f307980a29**d8" to attempt login to
> loads of other services.
>
> Hashed passwords only provide protection if the REAL password goes over
> the network.  In this case, knowing "**9f9d51bc70ef21ca5c14f307980a29**d8"
> is useless unless you can invert the hash, which is supposed to be
> computationally infeasible.
>
>     tom
>
>
> On 8/28/12 11:58 AM, Jason H wrote:
>
>> I'm tired of this. Security breach after security breach. Poorly
>> developed websites expose passwords, and even the hashed passwords are
>> no longer "good enough" due to hash databases.
>>
>> It is time we do something to fix this very broken area of the web. We
>> cannot trust our web software writers to do a quality job. Obligatory
>> XKCDs:
>> http://xkcd.com/936/
>> http://xkcd.com/792/
>>
>> 792 is particularly interesting because in this one, a hostile website
>> owner is attempting to collect passwords for guessing at other sites.
>> This is a Huge problem.
>>
>> I propose a simple technique to solve these problems, however I want it
>> as part of HTML5.
>>
>> The cryptographic solution (evolution to the solution):
>> For any <INPUT TYPE="PASSWORD">, we hash the contents before submit. If
>> I enter the well-known and insecure password of "bob" the submitted
>> contents for this are changed to "**9f9d51bc70ef21ca5c14f307980a29**d8"
>> which, on an insecure site are stored as
>> "**9f9d51bc70ef21ca5c14f307980a29**d8" This helps a little bit, but the
>> hash
>> is well-known. Therefore, we must also take the domain from the action
>> (<FORM ACTION="arstechica.com/some/**url/login.php<http://arstechica.com/some/url/login.php>">
>> = arstechnica.com)
>> and salt the password accordingly "arstechica.com:bob" =
>> "**664b9f0d0528f5a5d2a389e5253bb9**92" and submit that instead of bob or
>> his
>> well-known hash. Now an attacker has to construct a hash database for
>> every site that is attacked, and also must know the salt and salt method.
>>
>> Importantly, all of this happens before the website owner gets to ever
>> see the original password, and the routine is provided by the browser.
>> Whatever the site does in addition (another hash, salt, etc) only helps
>> to secure the site further.
>>
>> I used MD5 to do the hashes above, however SHA1 should be used because
>> it is 8 hexadecimal digits longer (40 characters, 1.786899e+62 key space).
>>
>> The HTML changes needed to accomplish this:
>> The <INPUT> element needs to have a "SECURE" attribute (values=[0|1])
>> for a transitioning period. The presence of this attribute indicates
>> that in the case of:
>> 0: The site knows it is not secure and the password is submitted as
>> plain text (as it is done today) or javascript will take care of it. The
>> browser may display a warning to the user that the site is asking for a
>> raw password. The software can then take a raw password and after
>> authentication produce an updated password entry by emulating the
>> hashing behavior that would be done in the browser. The password may be
>> truncated to fit existing password semantics.
>> 1: The site knows it is secure and has a secure password on file for the
>> account. It will allow 40 characters of hexadecimal digits.
>>
>> If the SECURE attribute is not present, then we are in a HTML4-5
>> transitional area. We could process it as we do now, however I'd like to
>> push the browsers to do the following:
>> For any PASSWORD input in a known URL (a URL in the history) it checks
>> to see if it migrated this password previously. If it has, then it
>> behaves as SECURE=1. If it hasn't then it treats it as SECURE=0. For
>> either of these situations though, a visual override mechanism is given
>> such that a "knowledgeable" user can choose weather or not a hashed
>> password is submitted. The toggle mechanism will start out as insecure
>> "unlocked" icon. They can enter text and click the icon which will
>> change the icon to a secure "locked" icon and the password will be
>> hashed. The user using unhashed passwords can then after logging in
>> change the password again, using an unlocked icon for the current
>> password, then entering the same password for new and retyped passwords,
>> then clicking the icon to lock and hash them. In this way a
>> knowledgeable user can use secure passwords on a site that does not yet
>> support this HTML5 password security. (Optionally browsers can support a
>> second click to the icon to "unhash" it) The password field should show
>> the 40 character length of the password.
>>
>> Also, for browsers that support remembering of passwords, and this has
>> been elected, the new password mechanism still works.
>>
>> Challenges:
>> 1. The migration phase may be messy. Browsers could make or break
>> acceptance of this.
>> 2. Existing password fields may truncate at 12 or fewer characters, or
>> require a character set not in hex (punctuation)
>>
>>
>> Comments?
>>
>>
>
>