News for hackers. Stuff that matters.
Re:Disqus Security Alert: User Info Breach by jMyles on Friday October 06, 2017 @08:20PM (#15421479)
Ahh, thank you. This is the kind of refutation I need. I'll read up and decide.

As for your specific qualm: I have to imagine that this can be solved by adding a numerically-determined nonce (so that I can say, "this is my 2nd password on disqus", etc) without having to fashion a new key.

edit: OK, so I have read the article. Here are my reactions to the author's four concerns:

* #1: Password schemes

> Unfortunately, sites have wildly varying and often conflicting password requirements: non-alphanumeric symbols are mandatory! Passwords must be alphanumeric only! Capital letters required! Passwords must be lower-case only! Passwords must be at least 12 characters long! Passwords must be at most 8 characters long!

> While many of these requirements seem silly and in a perfect world all sites would adopt the new NIST password guidelines, reality is messy and there is no single deterministic password generation scheme which can accommodate the password policies of all sites.

There aren't that many different schemes. Maybe a grand total of three dozen? I think that the program can simply have a user-updated registry (perhaps that's shared) of schemes, and the generator accounts for this. This seems like... maybe 150 lines of Python.

#2) Revocation and new passwords

> We could ask the user to remember the site-by-site counter and input the correct counter value to derive the correct password. But I think this is silly.

Umm, that's a strange argument. I don't think that's silly. I think it's highly practical. Currently, users remember a shitload of different details for different domains, including different usernames (this one was taken here, that one didn't meet the scheme there, etc) and often slightly different passwords.

Making them remember an integer that will rarely be larger than 3 instead of a password seems awesome. Worse case scenario, they can keep trying until they get the right one.

> You can’t store credit card numbers or bank account numbers in such a vault.

> You can’t put arbitrary cryptographic keys in such a vault.

> You can’t store randomly selected answers to security questions in such a vault.

> I consider this to be part of the basic functionality of a password manager.

I don't know what to say except that... I don't. I'm happy to have a password manager literally just manage passwords and allow me to use other tooling (like form memory in a browser) for this other stuff.

> Exposure of the master password alone exposes all of your site passwords...If you accidentally type or paste your master password into email, IM, or social media, an attacker can leverage that alone to derive all of your site-specific passwords.

Yeah, I get it - that's the same argument the others in this thread are making.

But I'm not going to accidentally type along seed, like a 10-word sentence with punctuation, into any of those places. This seems like a completely absurd argument to me.

Re:Disqus Security Alert: User Info Breach by Arcsech on Friday October 06, 2017 @08:28PM (#15421507)
That's effectively no different from changing the seed data (say, going from "password1" as the seed to "password2"), you still have to remember which iteration you're on on each site as part of the seed data.

Edit: and this point is actually made in the article the GP linked.

Re:Disqus Security Alert: User Info Breach by pwg on Friday October 06, 2017 @11:31PM (#15422137)
> There aren't that many different schemes. Maybe a grand total of three dozen? I think that the program can simply have a user-updated registry (perhaps that's shared) of schemes, and the generator accounts for this.

> Making them remember an integer that will rarely be larger than 3 instead of a password seems awesome.

Ok, so, we have the "master seed" that has to be remembered. We also now have to remember X from [1..36] of schemes, and a Y version integer.

There's two ways to "remember" these triplets. In your head. I which case you have to remember, for all 50 [1] different logins to all the sites you have, a triplet of <master,scheme,version>. Master will be easy, as it will be typed enough times to be easily remembered. But remembering that site A, that has not been visited for 4 months, used <master,14,2> while site B, that as not been visited for 6 months, used <master,27,3> and so on for 50+ logins will be untenable.

Or your 'deterministic' generator really has to store the "scheme" and "version" parts of the triplet somewhere in a local file/db, associated with each site, to allow it to work. At which point, you are 80% of the way to a proper password manager that would allow each password to simply be a proper randomly generated string of characters, tailored as need be, for each site.

> Worse case scenario, they can keep trying until they get the right one.

Unless, because of breeches or general password rotation they are now up to "version 12", but the site only allows three tries until lockout. Now you have to start trying "within 3 steps" of 12 or else you are guaranteed to be locked out.

[1] In the manager I use (Password Gorilla, https://github.com/zdia/gorilla, which is one of the many Password Safe compatible managers) I've got 371 stored entries, of which 285 are actual passwords for various sites that wanted a registration of some form or another along the way. That is something you learn quickly when you start using a password manager. The sheer number of websites that want you to 'register' in some way or another is actually huge. This is after about 13 or so years of using a password manager.