Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

you don't need to backup a shared secret to gain exactly what you get from backing up a shared secret, except more secure

you have a backup of a _different_ secret with a similar degree of "authority" (or if it's "copyable" with the only authority to be used for restoring 2FA once or similar)

then if you backup gets stolen you can just go into you account management API and disable/delete/flag it, in that case even if encryption is broken as long as you act fast enough the damage is trivially and conveniently contained (e.g. some password managers had insecure backup/storage in the past)

with the same key not only do you have to disable it, you first have to create a new key and then sync it to all your new devices and backups and then disable the old key, which isn't grate if you have more then one device or some of you devices are temporary out of reach (e.g. you one a business trip)

it's like reintroducing the "physical" problem of having to replace all locks when you loose your house key in a situation where you could have all the benefits one key per lock and a different door for each person (i.e. device) without any of the overhead/drawbacks this would normally introduce



The main issue I see happening here with a large list of keys is the lack of an automated way of making these backups: this would require a standard way for a backup system to use one set of secrets to authenticate another set of secrets, which AFAIK doesn't exist for webauthn (it must be initiated by the site, all of which will have different methods of doing so). Otherwise you would have to manually enroll multiple devices for each account, which is both painful and error-prone.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: