Ask HN: What Will Replace Passwords?
Is FIDO Alliance the way of the future or something else?
7 comments
Passwords are just access secrets. Access secrets and always have, and always will be around. The implementation changes, not the idea.
With that said I believe the next generation of implementations will involve encrypted biometrics. Face ID sucks in that I have to hold my phone to my face. But it’s amazing that I don’t need to type a string password.
Biometrics is the future imo
With that said I believe the next generation of implementations will involve encrypted biometrics. Face ID sucks in that I have to hold my phone to my face. But it’s amazing that I don’t need to type a string password.
Biometrics is the future imo
Biometrics represent identity and not authority. This misconception will be the cause of many a security fail during the 21st century.
Authority comes from the user's mutable grey matter - not their immutable genetics.
Authority comes from the user's mutable grey matter - not their immutable genetics.
Yea my comment is in terms of identity not authorization. I didn’t read the FIDO part
Something like this
https://puri.sm/products/librem-key/
https://puri.sm/products/librem-key/
https://www.grc.com/sqrl/sqrl.htm was designed for that possibility.
Bitcoin's BIP32 (Hierarchical deterministic wallets) could be part of a solution. Currently they're used for bitcoin wallets, but they are more generally applicable for creating hierarchies of private/public key pairs, not necessarily attached to bitcoin addresses. A single private key and chaining key is all that is necessary to rematerialize all of the other keys in the hierarchy - a "master password".
A public key is superior to a password. It has more entropy to begin with, more than enough to resist brute force attempts, and it is sufficient, by itself, to establish an encrypted and authenticated communication with the holder of the corresponding private key. The key holder can sign messages asserting their ownership of the private key without revealing it, or can prove, if somebody already knows they are the owner of a public key, that they've signed a document that nobody else could have generated such signature for without possession of the private key.
For 2FA protocols and such, it may be possible to use threshold signatures to have messages signed by multiple parties which a verifier can verify at least M of N parties contributed to the signature without revealing necessarily who each the M parties are. There's much greater flexibility that can be gained here than simply having 2FA, which is often really just 1FA because it is done by SMS or some other weak form of authentication which can be vulnerable.
In addition, BIP39 (Mnemonic seed phrases) provide a more intuitive way of representing the initial data used to create the master private key. A RNG generates 256 bits of entropy, adds a checksum of 8 bits, and segments it into 24 chunks of 11 bits. The chunks each represent a word in a 2048 word dictionary, and the word phrase is recorded for future. The word phrase, when hashed, generates the master private key and chaining key for use with BIP32. Optional passwords can be used in conjunction with the word phrase to establish multiple disjoint key hierarchies from the same set of words.
This combination is now used in most bitcoin software and is fairly well understood by most bitcoin users. It's supported by several hardware wallets/HSMs, and likely many more will be coming. The burden is on the user to write down and safely store a 24 word phrase, plus optional passwords. There are some products on the market which can preserve this information in the event of natural disasters.
A missing part of the puzzle is to establish the relationship between identities the user cares about and the key paths in the hierarchy. Current conventions use path's such as `m/0'/1'/1` to mean the second child of the second child of the first account in the hierarchy. This doesn't carry around any information about what this specific key is used for - so there would need to be a separate tree stored somewhere (eg, user's device, backed up in cloud) which maps identities to paths. Access to this file would at most, reveal the identities the user has with different services, but would not reveal any private keys which could be used to access those services, as they're stored independently - preferably on a HSM which requires physical access.
A public key is superior to a password. It has more entropy to begin with, more than enough to resist brute force attempts, and it is sufficient, by itself, to establish an encrypted and authenticated communication with the holder of the corresponding private key. The key holder can sign messages asserting their ownership of the private key without revealing it, or can prove, if somebody already knows they are the owner of a public key, that they've signed a document that nobody else could have generated such signature for without possession of the private key.
For 2FA protocols and such, it may be possible to use threshold signatures to have messages signed by multiple parties which a verifier can verify at least M of N parties contributed to the signature without revealing necessarily who each the M parties are. There's much greater flexibility that can be gained here than simply having 2FA, which is often really just 1FA because it is done by SMS or some other weak form of authentication which can be vulnerable.
In addition, BIP39 (Mnemonic seed phrases) provide a more intuitive way of representing the initial data used to create the master private key. A RNG generates 256 bits of entropy, adds a checksum of 8 bits, and segments it into 24 chunks of 11 bits. The chunks each represent a word in a 2048 word dictionary, and the word phrase is recorded for future. The word phrase, when hashed, generates the master private key and chaining key for use with BIP32. Optional passwords can be used in conjunction with the word phrase to establish multiple disjoint key hierarchies from the same set of words.
This combination is now used in most bitcoin software and is fairly well understood by most bitcoin users. It's supported by several hardware wallets/HSMs, and likely many more will be coming. The burden is on the user to write down and safely store a 24 word phrase, plus optional passwords. There are some products on the market which can preserve this information in the event of natural disasters.
A missing part of the puzzle is to establish the relationship between identities the user cares about and the key paths in the hierarchy. Current conventions use path's such as `m/0'/1'/1` to mean the second child of the second child of the first account in the hierarchy. This doesn't carry around any information about what this specific key is used for - so there would need to be a separate tree stored somewhere (eg, user's device, backed up in cloud) which maps identities to paths. Access to this file would at most, reveal the identities the user has with different services, but would not reveal any private keys which could be used to access those services, as they're stored independently - preferably on a HSM which requires physical access.
Face id