Project Abacus, a.k.a. Google is terrible at security
-
@dkf Quite. That said, to get the same levels of entropy as a 13 character password taken from a 94 or 83 character set (about 80 bits in both cases, the difference is negligible), a 4 word password needs to be randomly picked from an "alphabet" of 500,000 words or so. If you drop the "alphabet" to 30,000 words, you need randomly picked 8 words to get the same 80 bits. 4 randomly picked words from that same 30k word alphabet gets you something like the same entropy as an 8 letter randomly picked password (but wins massively on ability to be memorised by the average person)
Why 30,000 words? Because that's a reasonable estimate of an average adult english speaker's vocabulary.
-
@another_sam said in Project Abacus, a.k.a. Google is terrible at security:
Not all 7 bits per character are used because some are unprintable.
i was assuming for the calculations of maximum entropy that all 7 bit ASCII characters were allowed, actual entropy will be lower than the maximum.
passwords are hard, password security is even harder when there are STILL companies out there that store your password in plain text (or reversably encrypted which may as well be the same thing because they have the decryption key too)
-
@tufty I keep mentioning this because it's the bomb because it makes passphrase generation so simple:
True hardware RNG!
Only 7776 words, so 12.9 bits of entropy per word. Choose enough words for your purposes. Combine with a password manager for best results.
-
@accalia said in Project Abacus, a.k.a. Google is terrible at security:
passwords are hard
And non-intuitive. And what most people "know" about good passwords is wrong. And the wrong policies are enforced as "best practice" when they're really just common dumb practice.
@accalia said in Project Abacus, a.k.a. Google is terrible at security:
there are STILL companies out there that store your password in plain text
My bank won't let me use a long passphrase for internet banking. Even worse, the mobile banking app on my phone is four-digit PIN only.
On the bright side, internet banking uses true 2FA, sending a confirmation code SMS to my phone for every transaction over some small limit. The mobile app, not so much.
-
@Gurth said in Project Abacus, a.k.a. Google is terrible at security:
@another_sam said in Project Abacus, a.k.a. Google is terrible at security:
Not all 7 bits per character are used because some are unprintable.
What’s stopping us from using control characters in a password, though? Other than web sites probably rejecting them and users being unable to enter them on a device like a phone or a tablet, that is.
What's stopping us from using these things, other than the things that are stopping us from using them?
-
@anonymous234 said in Project Abacus, a.k.a. Google is terrible at security:
"artificial fingerprint kits" of some sort would start appearing
Already here…
-
@ben_lubar said in Project Abacus, a.k.a. Google is terrible at security:
I object to passwords I can't change.
You can change your DNA, given enough stem cells. Or radiation.
-
@Lorne-Kates said in Project Abacus, a.k.a. Google is terrible at security:
@ben_lubar said in Project Abacus, a.k.a. Google is terrible at security:
I object to passwords I can't change.
You can change your DNA, given enough stem cells. Or radiation.
I thought radiation just lowered your max HP.
Filed under: FO: New Vegas was better than FO4. There, I said it.
-
I have a solution for passwords.
Don't store them. Instead, store the IP address of the user.
When the user comes back, if they enter anything into the password box, return TRUE. Users get frustrated when they are met with things like "invalid password", or have to jump through hoops like resetting a password. It's a Negative User Experience.
If someone tries to log into an account with a different password, return FALSE twice. On the third try, return TRUE and whitelist that IP address. If a hacker comes with what they think is the "correct" password, they'll get the FALSE and give up, figuring they actually have it wrong. The real user will be persistent, and will get in. It's a mild Negative User Experience, but worth it in the name of security.
And best of all, no one ever has to know their passwords aren't doing anything. Users will always assume they are entering the right password, and will feel safe. Hackers will give up, and thus the site WILL be safe.
You're welcome.
-
@Lorne-Kates said in Project Abacus, a.k.a. Google is terrible at security:
Don't store them. Instead, store the IP address of the user.
I'm afraid this idea would create an overly negative user experience for users whose ISP DHCP server changes their address frequently. Perhaps we should whitelist at the ISP subnet level instead?
-
@Dreikin said in Project Abacus, a.k.a. Google is terrible at security:
@Lorne-Kates said in Project Abacus, a.k.a. Google is terrible at security:
Don't store them. Instead, store the IP address of the user.
I'm afraid this idea would create an overly negative user experience for users whose ISP DHCP server changes their address frequently. Perhaps we should whitelist at the ISP subnet level instead?
Brillant! See, this is why Team Design Standup Meeting Scrums make for good software.
-
@error said in Project Abacus, a.k.a. Google is terrible at security:
What's stopping us from using these things, other than the things that are stopping us from using them?
My thinking was that you could use a program to output a string containing non-printing characters, then copy-and-paste that into the password field. Doing a little testing just now, though, it seems that last bit doesn’t work, since the non-printing characters are lost during either the copying or the pasting.
-
@Lorne-Kates And how do you protect against brute force methods?
-
@Vault_Dweller Require the same password to be typed in twice in a row (in the same session).
-
@dkf You know what they say about trying the same thing and expecting different results: it increases usability.
-
@Vault_Dweller said in Project Abacus, a.k.a. Google is terrible at security:
@Lorne-Kates And how do you protect against brute force methods?
No one is going to keep typing passwords, so I don't think that'll be a problem.
Or we just hard code in some protection:
if($logins ==3) { if( ($login1.endsWith("1") || $login1.endsWith("a")) && ($login2.endsWith("2") || $login2.endsWith("b")) && ($login3.endsWith("3") || $login3.endsWith("c")) ) { DoBanIPBecauseThisIsBruteForce(); } else { LegitUserWhitelistIP(); } }