4 ms·

I haven't heard of any system that replaces passwords all the way. Apart from usability most systems eighter rely on things that are hard to change (biometrics)

by chme 8y ago

I haven't heard of any system that replaces passwords all the way. Apart from usability most systems eighter rely on things that are hard to change (biometrics), things that can be copied (keyfiles, cookies, software) or things that can be stolen (hardware token). So they don't replace something that you have to remember (password). Passwords are easy to change and while they can be copied, that would be the result of the user or the login software doing something stupid. Not something wrong with concept of the password login itself. IMO those systems can be used to make the login more secure but replacing password all together not so much.

will4274 8y ago
> Apart from usability most systems eighter rely on things that are hard to change (biometrics), things that can be copied (keyfiles, cookies, software) or things that can be stolen (hardware token). Actually... When you log on with a password today, an Identity Provider like Google or Microsoft typically issues you a "ticket granting ticket" (TGT) which you can use to get more tickets. The TGT is stored in a cookie on the web or in the OS. This TGT is something that be can copied. So, today, when you log on, you provide your password to get something that can be copied that you then use to log on to various services. Point being, something that can be copied is in the flow anyway, so switching from password to something that can be copied and revoked is only an improvement.
- chme 8y ago
  "copied" in my case is something negative. I meant that as this information is stored unencrypted somewhere and can be just copied and used by an attacker to authenticate as an specific user. The ticket or cookie or what ever is just used to signify to the system that you are authenticated as user x and specific to http because it is stateless. So an implementation detail and not part of the authentication concept. I meant cookies here as data that lives in the browser forever or until the user requests a new one just using that cookie alone. And removing that cookie results in locking that account forever.

by chme 8y ago

will4274 8y ago

> Apart from usability most systems eighter rely on things that are hard to change (biometrics), things that can be copied (keyfiles, cookies, software) or things that can be stolen (hardware token). Actually... When you log on with a password today, an Identity Provider like Google or Microsoft typically issues you a "ticket granting ticket" (TGT) which you can use to get more tickets. The TGT is stored in a cookie on the web or in the OS. This TGT is something that be can copied. So, today, when you log on, you provide your password to get something that can be copied that you then use to log on to various services. Point being, something that can be copied is in the flow anyway, so switching from password to something that can be copied and revoked is only an improvement.

chme 8y ago
"copied" in my case is something negative. I meant that as this information is stored unencrypted somewhere and can be just copied and used by an attacker to authenticate as an specific user. The ticket or cookie or what ever is just used to signify to the system that you are authenticated as user x and specific to http because it is stateless. So an implementation detail and not part of the authentication concept. I meant cookies here as data that lives in the browser forever or until the user requests a new one just using that cookie alone. And removing that cookie results in locking that account forever.