phc-discussions - Re: [PHC] A silly (?) consideration for script-friendly hashes

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Fri, 24 Jan 2014 14:51:06 -0800
From: Andy Lutomirski <luto@...capital.net>
To: discussions <discussions@...sword-hashing.net>
Subject: Re: [PHC] A silly (?) consideration for script-friendly hashes

On Fri, Jan 24, 2014 at 2:42 PM, Bill Cox <waywardgeek@...il.com> wrote:
> On Fri, Jan 24, 2014 at 5:13 PM, Andy Lutomirski <luto@...capital.net> wrote:
>> If people are planning on having client-side offload, or, more
>> generally, if whatever hash wins ends up with a highly optimized
>> implementation in web browsers, there may be a problem: anyone who can
>> get people to leave their browsers pointed at pictures of kittens that
>> compute hashes in the background effectively has a big network of
>> password hashers.
>>
>> This can be mitigated: in addition to salt, a hash function could take
>> a domain as input.  Then web browser interfaces could enforce a
>> same-origin policy on the domain parameter.
>>
>> (This adds minimal implementation complexity: just hash the domain in
>> with the salt before using it to hash a password.)
>>
>> --Andy
>
> I think this is supported in Catena and Escrypt already.  Catena calls
> it "data", and Escript calls it "local parameters", but what it adds
> up to is the caller can add any application specific data they like,
> including the URL the browser is pointing to.  My favorite ideas for
> using such fields are TrueCrypt key file hashes, and secondary
> password specific secrets decrypted on the server with a master key.
>
> So, all your solution requires is that all the browsers implement
> native implementations of the password hashers, with an extra domain
> input.  I think that's a great idea, though it will be a while before
> that happens.

I'm suggesting that the final PHC algorithm specify an actual way to
encode the domain.  That will give the browser vendors something to
implement.

For this to work, browsers MUST NOT (in the RFC sense) provide an
unrestricted interface to set local parameters.

Here's a more concrete suggestion:  The "local parameters" should
perhaps have an extensible list of tag, value pairs.  Tags that start
with "secure." should have the property that scripting interfaces MUST
NOT allow them to be set unless they are familiar with the particular
tag, and, in that case, they should enforce constraints on the tag.

Then someone could define "secure.origin" or "secure.domain" with the
semantics we want.

Later on, someone could add "secure.userid" that requires that someone
actually type the userid into a form.

--Andy