On Sat, Nov 17, 2012 at 9:51 AM, Kyle Creyts <kyle.cre...@gmail.com> wrote:
> giving it an extremely brief run-through, I'd say that you've made a > different compromise than the app-maker chose in making the limit 8. > > the choice of 8 base64 digits out of the 24 given by the md5 appears > to have been explicitly done to combat attempts to attack the master > password, or other account passwords, based on the possession of any > one (or several) account passwords and nicknames or labels. > > while you may have succeeded in making your individual passwords > somewhat harder to brute-force, you've also used a larger portion of > the md5, increasing the amount of information an attacker is given by > the compromise of an individual password, and shrinking the number of > possible candidate md5s they would have to guess to attempt to collide > in hopes of getting your master password. Interesting point, but IIUC, the difference is that if they come up with N master passphrase (MP) candidates knowing a nickname and an 8 character password, then with a 16 character password, they'll end up with sqrt(N) candidates (am I right? I'm using "intuitive math" here). My intuition also says N wouldn't be very large (in the sense that trying all N would be a lot less work than finding them), and reducing the work by a factor of sqrt(N) wouldn't be much of an achievement. N can also be reduced further by sorting the MPs by heuristics re the likelihood of a string being a human-memorable MP (would mainly consist of dictionary+leet, dates, phone numbers, etc.). My intuition tells me such heuristics were researched already (am I right?). > in addition, they would > likely have to have at least another of your passwords and nicknames > to confirm the plausibility of the correctness of a given collision > for a given MD5 guess, if I understand it correctly. Not sure the nickname is needed. My intuition says most [l]oplop users would have some simplistic method for picking the nickname (otherwise they'd have to write them down and end up with a cumbersome equivalent of a traditional password manager). Chances are that the other nickname (you already know) of the user looks like alice@twitter,TwitterAlice2012, etc. and you can get a high success rate with a very small manually-prepared dictionary of guesses. > > only using base64 strings with numbers in them, and prepending a 1 in > some cases... this seems like it would shrink the keyspace/randomness > by at least a few bits. shrug. > > I feel you :) That weird make-sure-there's-a-digit trick makes distribution of 1 as first character higher than "in nature" (by how much? I hope it doesn't matter). Why not something like, say, xor-hash-bytes-mod-10? I've maintained this behavior in order to have an "oplop compatibility mode", because users are likely to have some legacy passwords (at least during a transition period). Let's hope it doesn't get any worse than a shrug :)
_______________________________________________ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
