- cross-posted to:
- [email protected]
- cross-posted to:
- [email protected]
It sounds like a cool concept, but I can’t see anyone migrating to this service since there is no logical way to import your current passwords.
Am I missing something?
It sounds like a cool concept, but I can’t see anyone migrating to this service since there is no logical way to import your current passwords.
Am I missing something?
This seems like someone learned about key derivation functions and applied it to passwords. So with this system, it’s stateless and no passwords are stored (encrypted or not). You need 4 things to generate passwords:
This seems counter intuitive to the stateless nature, since at least one (the spectre secret) will need to be stored somewhere. For UX the full name probably would also be stored, and the site domain can be gotten via some API on password use. This leaves the master password as the only portion not stored, and on “unlocking” the database it would probably be stored on the users device for a period of time.
This also ignores some of the requirements of websites needing passwords (some support all characters, some only a-z0-9_, etc etc). If supported, this metadata would also need to be stored somewhere. The cons of not being able to change passwords is also a huge issue, as passwords should be changed often, or replaced with keys (which you also replace often!).
For attackers, this seems not much different than a database file. In most cases, they’ll already know two of the 4 (site domain and full name, especially in corporate environments). This leaves only the spectre secret and the master password doing the heavy lifting of security. This sounds a lot like a traditional password manager, where you have a master password, a database file, and an optional key file.
So the process to attack a traditional database system is to acquire the needed information (database file, master password/key file) and lookup the password (site domain/description). The process to attack spectre is to acquire the needed information (full name, secret, master password) and lookup the password (site domain/description). These have the same challenges of acquiring/brute forcing the master password and key file, and are essentially the same in the eyes of an attacker.
Overall I think passkey’s will replace passwords, or something along that line. Keys have been used for a long time in security sensitive areas, can be swapped out easily and provide much more protection than a password when large enough.
Any “password” that cannot be revoked is a bad password.
This is also why biometrics are bad. You can’t replace your fingers, eyes, etc… These are good usernames.
I don’t think passwords have to be changed very often. When you use a password manager and 30 character random generated passwords (or why not 64 characters or even more if the site allows it) separately for each site. If there isn’t a breach: why should I change the password?
That’s a singular used very complex password which only my password managers knows changed against another singular used very complex password which only my password manager knows.
If it is long enough, even brute force shouldn’t be a problem if someone is trying every single combination possible for 30 or more characters (where he doesn’t know how much characters he has to find). 🤷♂️
Often is probably a bad way to phrase it, but there is a reason TLS certificates are changed regularly. Generally this isn’t a big concern if you are the sole user and a set of known devices are used. Once you start handing passwords to others to use (such as is common in corporate environments) the problems being to show. Resetting the password is just a sure fire way to revoke access to anyone that may of had access that shouldn’t, for whatever reason.
You are correct though, that as long as the password isn’t being used on public terminals or in areas it might be compromised, it’s generally secure.