2 ms·

> That's not what the vast majority of people do and thats fine, but some of us do for the sites that are important, and that is better then storing something

> That's not what the vast majority of people do and thats fine, but some of us do for the sites that are important, and that is better then storing something in a password manager weather it be passkey or password. > For example, both of the banks I use (in two different countries) only allow a fixed size 6 digit numeric password. Somewhat strict password length requirements are not very unusual. that is a problem with the banks, mine is happy with my 30+ one and has MFA. Banks that can't even support a decent password are unlikely to support passkey anytime soon > way underestimating how fast you can crack passwords nowadays if the service uses password hashing algorithms that are still commonly used if the provider (bank) is compromised and salted passwords leaked it doesn't matter, they have already compromised the bank and your account. And i still do not think you can quickly crack a password such as "This15aVERY!!securepasswordEH?!!?"? i could be wrong here > if you can memorize it long-term, it means you don't have enough entropy, and if you have enough entropy, it means you can't memorize it long-term not talking about bitcoin seeds here, just accounts. like i'm not arguing against passkeys just that they have the inherent flaw of existing on a device/somewhere vs something that doesn't.

someplaceguy 3y ago
I agree with your post. I'd just like to add a couple of comments: > if the provider (bank) is compromised and salted passwords leaked it doesn't matter, they have already compromised the bank and your account. It matters if the only thing that was leaked/compromised was the hashed password database, but not much else. In fact, the ones who leak the hashed passwords may not be the same as those who hack your accounts, just look at all the leaks tracked by https://haveibeenpwned.com https://haveibeenpwned.com and consider that anyone could download those hashed passwords and crack them. > And i still do not think you can quickly crack a password such as "This15aVERY!!securepasswordEH?!!?"? i could be wrong here You could be right, but I wouldn't be surprised if you were wrong here... Decades ago, the "John The Ripper" cracker was already very good at cracking these kinds of passwords (when CPUs were single core and much, much slower, and it wasn't even possible to run software on a GPU). John the Ripper was already capable of using many extremely extensive word lists (in different languages) to quickly run through many such passwords, and simply mutating the password by using l33t speak and adding a few numbers, symbols or using mixed case are extremely popular password strengthening techniques which the software was still capable of cracking very quickly, since that doesn't add much entropy. Although at the time it probably couldn't crack such a "long" password, I'm sure this type of software has become better and the hardware has definitely become many orders of magnitude faster and more parallel, so I wouldn't be surprised if the example you mentioned is well within "can crack quickly and relatively cheaply" territory, even when using salt, as long as the service is using a traditional password hashing algorithm (and not one of the newer compute-hard or memory-hard KDFs). I mean, to have an idea of the magnitude of the problem, the brainwallet cracking stories of a decade ago were already pretty mindblowing (even considering that it's a "no salt" scenario). I don't remember the exact details, but I think there were cases of people using an airgapped computer to compute the SHA-256 hash of some obscure passage of some obscure book or poem in some obscure language and the bitcoins were stolen within seconds of being transferred to these wallets (although, yes, due to the "no salt" problem, it stands to reason that all of these wallets were pre-computed by the attacker). But still, personally I'd feel a lot more comfortable just using and storing a completely random password with a perfectly known amount of entropy, just to be safe, and deal with the compromised device problem in some other way (such as having a dedicated password management device, like a hardware wallet, if you're really that paranoid).

someplaceguy 3y ago

I agree with your post. I'd just like to add a couple of comments: > if the provider (bank) is compromised and salted passwords leaked it doesn't matter, they have already compromised the bank and your account. It matters if the only thing that was leaked/compromised was the hashed password database, but not much else. In fact, the ones who leak the hashed passwords may not be the same as those who hack your accounts, just look at all the leaks tracked by https://haveibeenpwned.com https://haveibeenpwned.com and consider that anyone could download those hashed passwords and crack them. > And i still do not think you can quickly crack a password such as "This15aVERY!!securepasswordEH?!!?"? i could be wrong here You could be right, but I wouldn't be surprised if you were wrong here... Decades ago, the "John The Ripper" cracker was already very good at cracking these kinds of passwords (when CPUs were single core and much, much slower, and it wasn't even possible to run software on a GPU). John the Ripper was already capable of using many extremely extensive word lists (in different languages) to quickly run through many such passwords, and simply mutating the password by using l33t speak and adding a few numbers, symbols or using mixed case are extremely popular password strengthening techniques which the software was still capable of cracking very quickly, since that doesn't add much entropy. Although at the time it probably couldn't crack such a "long" password, I'm sure this type of software has become better and the hardware has definitely become many orders of magnitude faster and more parallel, so I wouldn't be surprised if the example you mentioned is well within "can crack quickly and relatively cheaply" territory, even when using salt, as long as the service is using a traditional password hashing algorithm (and not one of the newer compute-hard or memory-hard KDFs). I mean, to have an idea of the magnitude of the problem, the brainwallet cracking stories of a decade ago were already pretty mindblowing (even considering that it's a "no salt" scenario). I don't remember the exact details, but I think there were cases of people using an airgapped computer to compute the SHA-256 hash of some obscure passage of some obscure book or poem in some obscure language and the bitcoins were stolen within seconds of being transferred to these wallets (although, yes, due to the "no salt" problem, it stands to reason that all of these wallets were pre-computed by the attacker). But still, personally I'd feel a lot more comfortable just using and storing a completely random password with a perfectly known amount of entropy, just to be safe, and deal with the compromised device problem in some other way (such as having a dedicated password management device, like a hardware wallet, if you're really that paranoid).