4 ms·

Probability says that it won't be duplicated, but what if it is? You can't say "no, sorry, you can't choose this password" because that leaks information. This

Probability says that it won't be duplicated, but what if it is? You can't say "no, sorry, you can't choose this password" because that leaks information. This is even ignoring adversarial attacks to try and get this or any birthday attacks. In my thinking about this problem from the IoT space lately, I've been thinking about servers assigning credentials to devices, rather than devices telling you their creds. Assign a UUID and let the device generate their password/key, and the pair gives you a multiplicatively large space.

JoeAltmaier 12y ago
That's an obsolete notion. You are not going to duplicate a 128-bit high-entropy number. Not in several lifetimes of our sun. Your notion is interesting. Anything that automates the client-side is good. People are terrible at managing a security contract 'by hand' {edit} really, this superstitious notion that random numbers are 'not good enough' is embedded in our programmer culture. Folks continue to use lame solutions instead of just buying into the uuid-as-foolproof-identifier. It totally eliminates whole classes of problems and bugs. And you should be more concerned your computer will be hit by lightening, become self-ware and win the lottery 7 times, and molecularly reorganize into a teacup, before that uuid will be duplicated anywhere/anywhen.
- _asummers 12y ago
  For the record, I'm not the one downvoting you (I don't even have that ability yet!). Security is always done in layers, though, and while you're correct that it is extremely unlikely, the chance is nonzero. As such you have to prepare for that and design your system to be resilient to these types of things. In castle terms, you trust that no one will ever breach your wall, but that doesn't mean you don't have guards and an armory inside for the unlikely event it does.
  - JoeAltmaier 12y ago
    No, no, a thousand times no. You do not have to prepare for the astronomically improbable. UUID collision is a myth, and should be treated as such.

JoeAltmaier 12y ago

That's an obsolete notion. You are not going to duplicate a 128-bit high-entropy number. Not in several lifetimes of our sun. Your notion is interesting. Anything that automates the client-side is good. People are terrible at managing a security contract 'by hand' {edit} really, this superstitious notion that random numbers are 'not good enough' is embedded in our programmer culture. Folks continue to use lame solutions instead of just buying into the uuid-as-foolproof-identifier. It totally eliminates whole classes of problems and bugs. And you should be more concerned your computer will be hit by lightening, become self-ware and win the lottery 7 times, and molecularly reorganize into a teacup, before that uuid will be duplicated anywhere/anywhen.

_asummers 12y ago
For the record, I'm not the one downvoting you (I don't even have that ability yet!). Security is always done in layers, though, and while you're correct that it is extremely unlikely, the chance is nonzero. As such you have to prepare for that and design your system to be resilient to these types of things. In castle terms, you trust that no one will ever breach your wall, but that doesn't mean you don't have guards and an armory inside for the unlikely event it does.
- JoeAltmaier 12y ago
  No, no, a thousand times no. You do not have to prepare for the astronomically improbable. UUID collision is a myth, and should be treated as such.