What about including a random salt when generating the key from the master password? The application could either generate the salt for you on first use (and recommend writing it down and keeping in a safe place) or allow entering an existing salt (e.g. when transferring to a new device).
That would make password guessing practically infeasible and two users sharing the same master password won't inadvertently break the system. --Felix > -----Original Message----- > From: cryptography-boun...@randombit.net [mailto:cryptography- > boun...@randombit.net] On Behalf Of Steven Bellovin > Sent: Wednesday, May 30, 2012 09:58 > To: Maarten Billemont > Cc: cryptography@randombit.net > Subject: Re: [cryptography] Master Password > > > 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 > > > > > > _______________________________________________ > cryptography mailing list > cryptography@randombit.net > http://lists.randombit.net/mailman/listinfo/cryptography _______________________________________________ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
