4 ms·

A little boring and reactionary, I think. Unguessable capabilities (long unchoosable URLs mostly) have been used to replace passwords. Plenty of systems refuse

A little boring and reactionary, I think. Unguessable capabilities (long unchoosable URLs mostly) have been used to replace passwords. Plenty of systems refuse to let users choose passwords, and many common password problems are totally mitigated by this design.

chme 8y ago
That depends on what you want to do. Do you want to authenticate the system of the user or the user him/herself? If its the latter, then how do you protect the link from other uses of this system? Encryption? And how are you encrypting something? Password? If you do it via a keyfile then how do you protect the keyfile? If you do it via a hardware token, how do you prevent other people from stealing and using it?
bad_user 8y ago
An URL with a randomized path in it is, technically, a password. Also note that the transportation mechanism is pretty weak. If the URL is passed over HTTPS, then that keeps your ISP from seeing it, however it can still show up in logs on the server side or the client side, in your history. A URL will be remembered or even cached by your browser, whereas a regular password won't, unless you explicitly allow it. A regular authentication mechanism doesn't necessarily suffer from these weaknesses. Consider that you can derive the server-side password, like a client-side hash which may even be time dependent, such that the actual password is never sent to the server. You can implement systems in which the password you know is never sent over the wire. Basically a randomized URL is semi-public and you need to treat it as such. There aren’t many alternatives to classic authentication mechanisms around. The only one I can think of is having authentication links emailed to you, but that’s also less secure and it simply defers the problem to a third-party.
- paulryanrogers 8y ago
  If those password-URLs are one time use then they are better than a static password. Still, it's likely those are managed via email which makes that a single point of failure.
tinus_hn 8y ago
Not the 'my password is on a post-it attached to my monitor' issue though.

chme 8y ago

That depends on what you want to do. Do you want to authenticate the system of the user or the user him/herself? If its the latter, then how do you protect the link from other uses of this system? Encryption? And how are you encrypting something? Password? If you do it via a keyfile then how do you protect the keyfile? If you do it via a hardware token, how do you prevent other people from stealing and using it?

bad_user 8y ago

An URL with a randomized path in it is, technically, a password. Also note that the transportation mechanism is pretty weak. If the URL is passed over HTTPS, then that keeps your ISP from seeing it, however it can still show up in logs on the server side or the client side, in your history. A URL will be remembered or even cached by your browser, whereas a regular password won't, unless you explicitly allow it. A regular authentication mechanism doesn't necessarily suffer from these weaknesses. Consider that you can derive the server-side password, like a client-side hash which may even be time dependent, such that the actual password is never sent to the server. You can implement systems in which the password you know is never sent over the wire. Basically a randomized URL is semi-public and you need to treat it as such. There aren’t many alternatives to classic authentication mechanisms around. The only one I can think of is having authentication links emailed to you, but that’s also less secure and it simply defers the problem to a third-party.

paulryanrogers 8y ago
If those password-URLs are one time use then they are better than a static password. Still, it's likely those are managed via email which makes that a single point of failure.

tinus_hn 8y ago

Not the 'my password is on a post-it attached to my monitor' issue though.