StrongPhrase.net - Random passphrases, passcodes, usernames, and identities

[AtomicBug]

Hi folks!

I created StrongPhrase.net about a year ago and have been adding little utilities to it over time. I wanted to share it with y’all and invite your feedback!

Memorable passsphrases (instead of passwords) • StrongPhrase.net

History: The core passphrase algorithm was created by Ryan Foster and I wanted to add a more modern UI around it. I then went on to write a deep FAQ about password entropy as a way to study the topic myself.

It has a few features:

• Passphrase generator + FAQ
• Phone passcode generator
• Username generator
• Identity generator
• Entropy time-to-crack and cost-to-crack table

Let me break these down and explain my reasoning:

Passphrase generator

• Easier to memorize: I love diceware, but I was having a hard time memorizing a new diceware passphrase. So, I did the very logical thing, which is spend days coding an app to the problem. I found Ryan Foster’s code which tells a mini story using different grammars
• Clean UI: I wanted to re-build it in React and Tailwind with a nice UI
• Learning: I wanted to learn more about password entropy and share what I learned with users
• Cost-to-crack: Along the way, I was compelled by the argument that cost-to-crack is much more useful than time-to-crack, given that someone can just pay for more cloud computer power (or even local computer power). I don’t see many password generators talking about cost to crack. So I wanted to make that available on the main generator and in the entropy table.

Phone passcode generator

• I have been working to encourage folks to switch to 10-digit random numeric passcodes (as a minimum). So I wanted an easy place to send them to.
• I did a lot of research trying to find the most up-to-date information about Cellebrite and GrayKey crack rates. The best data I could find was 25 guesses/second, but the data is from 2018. If anyone has more up-to-date info, let me know
• I also took the extra step of making sure that the 6-digit passcode never returned any common passcodes like “123456” (got the most common RockYou passwords that are 6-digit numeric strings, and took the first 10,000) or any date combination in any format (YYMMDD, MMDDYY, DDMMYY).

Username generator

As I continued on my privacy journey, I started more frequently using pseudonym identities for each new account. Again, I coudln’t find any random username generators that I liked. Many of them required a keyword that would get modified. I just wanted something random. I already had the word lists set up for this, so it was an easy addition.

• I plan to add a few other formats because just using animal names gets a little boring

Random identity generator

• Once again, I didn’t like the other identity generators I found online. Mostly I wanted something prettier. And to use the disposable mail services I found most user-friendly.
• I also wanted it to have avatars that I found more appealing
• At first I only had one avatar set, but I wanted to not have all my identities online use the same set, since that creates a more clear trail. Mixing it up among avatar types that are popular across the web helps keep these identities unlinked from one another.
• Just today, I added a “Save to 1Password” button. It saves it as. “login” which isn’t ideal. It should be an “identity” instead. But 1Password doesn’t allow that option, so this is the best we’ve got.

Entropy time-to-crack and cost-to-crack table

• I find myself often just wanting a quick lookup table for time-to-crack (with different computer power options) or cost-to-crack.

Open to feedback with any/all of this! Thanks, folks!

[basenote]

Yeah, I played around a bit and your website has already been useful to me. Thank you for making it. And please continue maintaining it.

[Critical_Crab5543]

I really like what you have done with your website, but I have one question. You say that pbkdf2 that, for example, 1Pasword uses, is stronger than bcrypt, but I’m not sure this is the case. According to this wikipedia article, bcrypt should in fact be stronger, and Proton uses bcrypt as well and while not as strong as something like Argon2, they have said that it is stronger than pbkdf2. Can you comment on this?

[patron]

I agree. In general bcrypt is more resistant to hardware acceleration attacks due to its design [1]. However, PBKDF2 can be stronger with very long passwords (over 72 bytes) or in environments requiring FIPS-140 compliance [2].

Estimated cost of hardware to crack a password in 1 year:

[3]

[mangomango]

Hey, thank you for sharing your service and congrats on realizing your project! I think it really adds something new. I will use it (for information on cost to crack, identity generator. I will keep using Bitwarden for passphrase, username, and phone passcode generator though.

Most importantly, it helped me a lot understand passwords, diceware lists, entropy, bruteforcing, etc.

[bitsondatadev (Brian "bits" Olsen)]

This is already so well done despite any small criticisms that may arise here! Well done and thank you!

These types of tools would honestly be cool to either list or potentially add to PG materials since it is listed under MIT license I assume you wouldn’t mind if the PG team wanted to maintain it.

[AtomicBug]

@bitsondatadev

These types of tools would honestly be cool to either list or potentially add to PG materials since it is listed under MIT license I assume you wouldn’t mind if the PG team wanted to maintain it.

Yeah, happy to have it listed and very happy to have co-maintainers if there was interest. I imagine PG has plenty of other things to focus on, but happy to open that conversation if there is interest.

[AtomicBug]

@patron

I agree. In general bcrypt is more resistant to hardware acceleration attacks due to its design [1]. However, PBKDF2 can be stronger with very long passwords (over 72 bytes) or in environments requiring FIPS-140 compliance [2].

Very interesting! I appreciate you pointing this out and the good links.

After looking into it a bit more, I think I was conflating PBKDF2 generally with 1Password’s implementation of it. Would it be correct to say that since 1Password uses a secret key (38 characters) + the master password and a high iteration count that it rivals bcrypt used with standard settings? I think some of the GPU “memory-hard” stuff is going over my head at the moment.

The real comparison I was trying to make was 1Password difficult to crack vs Hive System’s time-to-crack crack table using their best guess of current consumer hardware and average password hashing algorithms they are seeing in breaches these days. They used to base their metrics on MD5, but they recently moved to bcrypt since it was becoming increasingly common.

I do the conversion in this table using Hive System’s A100 x 10,000 GPUs and converting it from guesses per second to guesses per dollar.

I assumed something was making PBKDF2 stronger since it was costing so much more and because 1Password (and Apple) chose it in the first place.

If anyone can help fill in the gaps in my knowledge here, I’d apperciate it! The question I’m asking is: why is 1Password so much most costly to crack at $6 per 2^32 guesses?

I suspect the answer may be: HiveSystem is just working with a different set of assumptions and I’m trying to compare apples to oranges (or just very different apples).

Thanks!

[jonah (Jonah Aragon)]

Firstly, the $6 figure is wrong, because at the time 1Password used 100,000 iterations.^[1] Currently, 1Password states:

Extrapolating from a cracking challenge we ran, we estimate it costs an optimized attacker working at scale between 30 and ~40 US dollars to make 2³² guesses against PBKDF2-SHA256 with 650,000 iterations.

(Also, @AtomicBug note that this has nothing to do with 1Password’s secret key, which does add additional security on top of the estimate above, but I won’t be covering that in this post. You can read their security design paper to learn more about that.)

I do not know how this compares to Hive System’s because I don’t really understand their testing methodology.

Also note that 1Password’s cracking challenge was completed far before the A100 even existed, so I don’t put too much faith in their “extrapolated” estimates holding up in the modern world. The real cost is undoubtedly somewhere between 1Password’s and Hive’s estimates, but I don’t know where it would land. Hive didn’t do any estimates with PBKDF2-SHA256, so their data isn’t directly applicable here.

---

Secondly, password hashing (what bcrypt does) is completely different from key derivation (what PBKDF2 is), which is what password managers need.

As the Wikipedia article @Critical_Crab5543 linked to says:

It is important to note that bcrypt is not a key derivation function (KDF). For example, bcrypt cannot be used to derive a 512-bit key from a password.

So bcrypt is completely irrelevant for password managers or other applications that are encrypting data using your password. It is only relevant for password hashing for regular websites.

What would be more secure than PBKDF2 is Argon2, but 1Password explains why everyone is using PBKDF2 succinctly:

The choice of PBKDF2-HMAC-SHA256 as our slow hash is largely a function of there being (reasonably) efficient implementations available for all our clients. While we could have used a more modern password hashing scheme, any advantage of doing so would have been lost by how slowly it would run within JavaScript in most web browsers.

Because key derivation is performed by the client (so the server never needs to see the password) we are constrained in our choices by our least efficient client. The Makwa password hashing scheme 13, however, is a possible road forward because it allows some of the computation to be passed to a server

---

For the sake of completeness, yes, I know there is one password manager claiming to use bcrypt:

Proton uses bcrypt for authentication because their authentication model is different than most password managers.

Under the hood, Proton actually uses OpenPGP S2K for their key derivation function.

Proton’s security is the equivalent of putting your password into bcrypt, taking the resulting hash, and then using that hash as the passphrase for your OpenPGP key.

It’s an interesting setup that really makes no sense for anyone to do unless you are basing all of your encryption on PGP like Proton is. For everyone else who can just do their own encryption without worrying about legacy PGP stuff, using a single function that is built for this purpose like PBKDF2 makes a lot more sense.

To be honest, S2K is far worse than PBKDF2, and Proton’s bcrypt solution is a hacky solution. I would be very sure to use a long and high entropy password with Proton, instead of only relying on bcrypt. On the other hand, you are (mostly) perfectly safe using a crap password with 1Password, because your account security is guaranteed with their separate high-entropy Secret Key. Other password managers like Bitwarden are somewhere in the middle.

PGP will eventually use Argon2, but I haven’t heard any additional news about that since Proton’s post in 2023 about it.

Edit: Apparently OpenPGP 6 with Argon2 support came out at the end of last year, so maybe Proton will support it soon.

---

1. Accounts created prior to January 27, 2023 and have not changed their account password or Secret Key since this date, will use a lower iteration count. The iteration count can be updated to the current standard value by changing either the account password or Secret Key.

   ↩︎

[POOLNNOB]

Regarding the phone passcode crack capabilities i asked something similiar in a topic last week.

What makes you think that cellebrite & co. are only capable of bruteforcing only around 250/sec passwords on modern SoC? If true it would mean every phone with a 8-10 psw is hardly accessible even for the best in class in the forensic industry. Just your opinion of course, let me know.

[jonah (Jonah Aragon)]

High entropy passphrases are the only guaranteed way to secure your data.

Mechanisms that prevent brute forcing shorter PINs are helpful and convenient because they let you use more memorable PINs, but they are just that, a convenience feature, they aren’t foolproof and can be exploited. It comes down to your personal security vs. convenience balance.

[mangomango]

@jonah

High entropy passphrases are the only guaranteed way to secure your data.

Not very pertinent, but this and passwords too. Like ogx!ULjre5xh8xSPxZyX&yaqU

[AtomicBug]

Thanks for taking the time to write this up, @jonah. I’m always grateful for your generosity!

And yeah, this reveals where I was clearly beyond the edge of my understanding when writing up the guide!

It may make sense for me to cut that table from the guide since you’re right, I’m comparing password hashing functions to key derivation functions. Which I did have mixed up until you pointed it up.

That said, I would like to keep the “cost to crack” table. But I’m left wondering how to make a good estimate on cost to crack.

The table @patron linked to is from 2009, I believe, so I find that hard to trust.

For my use case, the cost to crack that matters the most is 1Password and Apple. Which can obviously be on a very different scale than someone who breaks a bunch of hashed+salted passwords from some website.

This is my project to take on so I’ll go do some more digging and see if I can find more up-to-date resources that I can learn from and integrate into the FAQ. Open to recommendations if anyone has any!

[POOLNNOB]

@AtomicBug my question was directed to you, let me know your opinion, thanks

[AtomicBug]

The 250 attempts/second “high end” crack rate for forensic devices is pure speculation based on the best-available information of 25 attempts/second as the actual guess rate. I fixed a 10x increase would be a reasonable high end of what they’re capable of.

Worth noting: This assumes that they can’t just bypass the passcode altogether. Which we know they can do (to varying degrees) for older phones and many out-of-date operating systems.

[POOLNNOB]

Yeah but why is only limited to 250 attempts and the gpu unit won’t make much difference? Cause they somehow exploit the phone processor maybe? So it happens only with the phone let’s say “capabilities of elaboration”.
Instead an offline bruteforce would be powered by many gpu altogether, I don’t get this point if you can explain.

Ps. Bypassing the lock screen BFU master password on a FBE phone would still mean the individual files are encrypted and need to be bruteforced singularly, imho but i could be wrong.