241–250 of 250 posts
Earlier quoted context omitted.
If you master password is weak, I don't think that bcrypt/scrypt in my tool would help when a breach has happened.
It absolutely would.
As I can't salt the hashes the attacker can precompute all the passwords he wants to try. If that takes 1 minute, it will take 1 minute for a database with 1 billion passwords and 1 minute for a database with 2 passwords.
Earlier quoted context omitted.
Why generate symbols that are not permitted anyway? You'd lose nothing by emitting the base16 encoding of the symbol.
Have you even used the internet much? Some sites do require symbols. And some sites have ridiculous rules that your suggestion would also not help with. Also, restricting yourself to the 16 characters in hex encoding makes your passwords that much easier to guess.
No. Entropy does not change by adding redundant bits.
Earlier quoted context omitted.
It absolutely would.
Care to elaborate? As I can't salt the hashes the attacker can precompute all the passwords he wants to try. If that takes 1 minute, it will take 1 minute for a database with 1 billion passwords and 1 minute for a database with 2 passwords.
Eight character random mixed alphanumeric password, hashed with say, sha256: crackable in hours with a GPU cracking rig.
Eight character random mixed alphanumeric password, hashed with scrypt using aggressive settings: could take years or decades to crack.
There is absolutely a large class of passwords that will be cracked if the hashing is fast, but not if it's hashed with a time and memory hard function.
You can make an attackers job literally over a million times harder at minimal cost.
Earlier quoted context omitted.
Have you even used the internet much? Some sites do require symbols. And some sites have ridiculous rules that your suggestion would also not help with. Also, restricting yourself to the 16 characters in hex encoding makes your passwords that much easier to guess.
> Also, restricting yourself to the 16 characters in hex encoding makes your passwords that much easier to guess. No. Entropy does not change by adding redundant bits.
You really are confused about this stuff.
You also seem completely unaware that many sites have password rules that require special characters that don't exist in your scheme... lol!
Earlier quoted context omitted.
Care to elaborate? As I can't salt the hashes the attacker can precompute all the passwords he wants to try. If that takes 1 minute, it will take 1 minute for a database with 1 billion passwords and 1 minute for a database with 2 passwords.
You could simply have people use their email address (or name) as a salt. Not great, but it would help significantly. Eight character random mixed alphanumeric password, hashed with say, sha256: crackable in hours with a GPU cracking rig. Eight character random mixed alphanumeric password, hashed with scrypt using aggressive settings: could take years or decades to crack. There is absolutely a large class of password…
This wouldn't work, as the attacker should know both from the database.
Anyway: If the user really wants, he can already add his email or name to one of the input fields. A salt is just another input to the hash function so this would be the same.
> Eight character random mixed alphanumeric password, hashed with say, sha256: crackable in hours with a GPU cracking rig.
Let's say by "several" you mean two. Then if
62^8 = 2 hours
62^12 = ~3374 years
And to do it the other way around (let's say that "years or decades" is 20 years):
62^8 = 20 years
62^5 = ~44 minutes
> scrypt using aggressive settings
Keep in mind that if a breach happens, the database is also hashed. And salted! So the attacker would need to crack that first anyway.
I use an algorithm. In short: 1. Memorize some base password 2. Memorize a way in which you mutate that password based on the name/type/other of the service logging in to. Eg. Hunter2 becomes eHunterG8 Because my example algorithm cares about Google's first letter, length, and service type: email. It allows every password to be different but you only memorize two things. It is meant to be a "good enough" solution tha…
Doesn't this compromise all of your passwords if one of your passwords is discovered? Sure, it would take a bit of thinking to realize what each part refers to and even realize that your password has some sort of generation algorithm, but it would be a bit more secure to hash that password in some way. That's why I like using LessPass (even though people talk a bit of shit about it whenever it's mentioned on HackerNe…
I am shocked to see a tech literate audience recommending a single algorithm based password. This is pretty basic stuff. Minimize attack surface! With a password manager, your attack surface is your email, and the password to the manager. You can focus your efforts on securing those two things with 2fa, a hardware device, etc. Every other password can be extremely difficult, and only grant access to an individual ser…
> Compare it to an algorithm, where your attack surface is "every service." If one password is compromised, they all are. My password for Amazon is "f3cfcb6ZUZ^". What's my algorithm?
https://lowe.github.io/tryzxcvbn/
https://blog.codinghorror.com/your-password-is-too-damn-shor...
You're talking about mitigating the risk of break-in by using an alternative to a password manager. I'd rather propse to use a self-hosted password manager on a VPS or in a cloud service. As long as that password manager is hosted securely, VPS for example, and uses your login password to help decrypt the stored passwords. Perhaps some HMAC required too. Anyone know if this exists in the open source world?
Earlier quoted context omitted.
You could simply have people use their email address (or name) as a salt. Not great, but it would help significantly. Eight character random mixed alphanumeric password, hashed with say, sha256: crackable in hours with a GPU cracking rig. Eight character random mixed alphanumeric password, hashed with scrypt using aggressive settings: could take years or decades to crack. There is absolutely a large class of password…
> You could simply have people use their email address (or name) as a salt. Not great, but it would help significantly. This wouldn't work, as the attacker should know both from the database. Anyway: If the user really wants, he can already add his email or name to one of the input fields. A salt is just another input to the hash function so this would be the same. > Eight character random mixed alphanumeric password…
You mentioned pregenerated lookup tables in a previous comment. Using email address as salt prevents that attack. Salts come with the database too.
> Anyway: If the user really wants, he can already add his email or name to one of the input fields. A salt is just another input to the hash function so this would be the same.
The proportion of people who would supply it as a salt is much greater than those who would otherwise prepend/append that data to the password.
> Meaning that a 12 character random mixed alphanumeric password would already take longer than the scrypt approach thanks to the way the exponential function works :)
Yes, but then the user has a more difficult password to memorize, so that argument is irrelevant. You should be thing about what actual humans actually do, rather than assume your users are technically sophisticated and willing to put in the effort to do the right thing.
> That's why I don't like to advertise with an "uncrackable hash function". In the end this might lead users to choose a shorter password, which is way worse!
Don't advertise it as such, but do it anyway, and explain the details in an FAQ.
> Keep in mind that if a breach happens, the database is also hashed. And salted! So the attacker would need to crack that first anyway.
It is entirely unreasonable to expect anything better than MD5.
Earlier quoted context omitted.
> You could simply have people use their email address (or name) as a salt. Not great, but it would help significantly. This wouldn't work, as the attacker should know both from the database. Anyway: If the user really wants, he can already add his email or name to one of the input fields. A salt is just another input to the hash function so this would be the same. > Eight character random mixed alphanumeric password…
> This wouldn't work, as the attacker should know both from the database. You mentioned pregenerated lookup tables in a previous comment. Using email address as salt prevents that attack. Salts come with the database too. > Anyway: If the user really wants, he can already add his email or name to one of the input fields. A salt is just another input to the hash function so this would be the same. The proportion of pe…
Ah right, didn't think of that!
I will think of adding a preference where one can add a salt value :)
> Yes, but then the user has a more difficult password to memorize, so that argument is irrelevant.
But while the password-remembering difficulty scales linearly, the difficulty to crack it scales exponentially ;)