On Wed, May 30, 2012 at 9:57 AM, Steven Bellovin <s...@cs.columbia.edu> wrote:
>
> On May 29, 2012, at 7:01 22PM, Maarten Billemont wrote:
>
>> Dear readers,
>>
>> I've written an iOS / Mac application whose goal it is to produce passwords
>> for any purpose. I was really hoping for the opportunity to receive some
>> critical feedback or review of the algorithm used[1].
>>
>> --
>> ABOUT
>>
>> With an increasing trend of web applications requiring users to register
>> accounts, we find ourselves with countless accounts. Ideally, each should
>> have a different password, so that authenticating yourself for one account
>> doesn't reveal your credentials of other accounts. That becomes really hard
>> when you've got tens or hundreds of passwords to remember.
>>
>> Solutions exist, mostly in the form of password "vaults" that list your
>> passwords and get stored in an encrypted form. Other solutions send your
>> passwords off to be stored on some company's cloud service.
>>
>> Master Password is different in that it generates passwords based purely off
>> of a user's master password and the name of the site. That means you need
>> no storage and have a fully offline algorithm that needs nothing more than
>> what you can remember easily.
>> --
>>
>> I'm rather a notice in the field of security (certainly in comparison to
>> some of you), and I was hoping that some of you might find the time to have
>> a look at the algorithm and see if there are any obvious flaws or risks to
>> the security and integrity of the solution.
>>
>> As a side-note, the iOS application, Master Password, is fully
>> open-source[2] under the GPLv3. If any of you speak fluent Objective-C, it
>> would be awesome if they could have a peek at the source code as well.
>
>
> From a very quick glance, it looks to be about the same as
>
> @inproceedings{web-pw-gen,
> Author = {J. Alex Halderman and Brent Waters and Edward W. Felten},
> Booktitle = {Proc. 14th Intl. World Wide Web Conference},
> Month = {May},
> Title = {A Convenient Method for Securely Managing Passwords},
> Url =
> {http://userweb.cs.utexas.edu/~bwaters/publications/papers/www2005
> .pdf},
> Year = 2005,
> }
>
> As someone else has noted, a crucial issue is that every site receives a
> function of your master password, the site name, and a counter that
> defaults to zero. If they launch a password-guessing attack -- and I
> know you've made it expensive, but you can't go too far in that
> direction without making user password retrieval too time-consuming, and
> the attackers have GPUs, botnets, and things like EC2 to parallelize
> their work -- they can retrieve the master password and hence all of
> your others. You can strengthen you scheme significantly by making the
> counter 8 bytes and starting it with some random value.
>
>
> --Steve Bellovin, https://www.cs.columbia.edu/~smb
>
Indeed, this has been done many times before, and although that is true,
Mr. Billemont should still be congratulated for his insight and I'm sure
he will make money off the irobot community; even though he is probably
(almost surely) stepping on some patents and prior work of others.
However Steve's modification does not fully repair this idea, in fact
it reduces the security given by the "master password" in comparison
to the random counter values to basically nothing.
As your new found secrets (the random counters) are stored plaintext
in the device (even if they aren't, so what? maybe we could encrypt
them with more random counters).
This leads to not only the scheme being completely device dependent
(try to ask a user to remember and IP, don't even consider 512 random bits)
And a device compromise being a terrible scenario. Obvious solutions
to this issue that I have considered are obviously flawed.
scrypt is also a terrible choice. Enjoy your free money.
_______________________________________________
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography
