Does this really need yet another blog post? 72 characters is more than enough to be resistant to brute-force attacks, as demonstrated by thousands of data breaches containing bcrypt hashes that remain uncracked (excluding the obvious top 1k passwords/ credential stuffing). In my personal opinion calling it "unsafe" is just fear mongering, especially in conjunction with a recommendation of using Argon2 which is comparatively very new and is probably safe - but once again, does not have the proven record that bcrypt does.
I agree 72 characters is plenty for most circumstances. However, as the blog points out, this is a byte limit not a character limit.
Some of the family emoji can be > 20 bytes. Some of the profession emoji can be > 17 bytes. If people are using emoji in their passwords, we could quite quickly run out of bytes.
I think it’s a limitation worth being aware of, even if “unsafe” is perhaps overstating it.
I still don't see how that's an issue, yes a password using a series of ridiculously complicated family emoji will be truncated but the actual bytes still provide entropy, just because the data doesn't use pixels when rendered doesn't mean it doesn't increase the search space
If your password is comprised of three emojis that each take up 24 bytes, then yes, a 72 byte truncation dramatically reduces the search space for a brute force against these hypothetical 24-byte-emoji-only passwords.
There are far fewer possible combinations of any three emojis than there are any 72 ASCII characters.
This is x^3 vs y^72, where X is the total number of distinct emojs and Y is the total number of distinct ASCII characters.
24 bytes of data is not 24 bytes of entropy if there are only a couple thousand different possible inputs to produce all of the possible 24 byte sequences produced by those inputs.
For simplicity: picture having only two possible input buttons. Each one produces 1000 bytes of random-looking data, but each one always produces the exact same 1000-byte sequence, respectively. You have a maximum password of 1 button press. The "password" may contain 1000 bytes, but you only have one bit of entropy, because the attacker doesn't need to correctly guess all 1000 bytes, they only need to correctly guess which of the two buttons you pressed.
Of course, in practice, not all emojis are 24 bytes, and I'd assume few people are using emoji-only passwords, but the distinction between bytes of data and bytes of entropy is worth clarifying, regardless.
I would argue that a password containing emojis is unlikely to ever be cracked, because no attacker is going to test emojis unless they have some reason to believe you use them in your password.
Attackers don't come up with every entry on the wordlist they throw into hashcat themselves. The attacker's imagination has essentially zero correlation with the contents of their wordlist.
Rest assured, the world's intelligence agencies and cybercrime rings aren't just taking vanilla open source wordlists off github and hoping they get lucky.
You don't know what your adversary's wordlist contains, and assuming you do is a recipe for overconfidence.
Yes, "if your enemy is state sponsored attackers" you shouldn't do many things, like use bcrypt incorrectly, or really passwords almost at all. That's obviously not what I'm saying.
The hash is 24 bytes. Even without an input character limit, you're likely to find tons of valid aliases for your 1000-character password within the 72-byte password space.
I never actually considered it until I read parent, and now I'm gonna try to start using it wherever it's supported, it's genius to use it for passwords as long as it's supported by the platform. Edit: Just to clarify, together with a password manager of course, otherwise I'd never have the patience for it.
Well, if you limit the discussion to passwords, you're right, maybe no need to worry especially if using randomly generated ones (like ones from password managers), but if the algorithm is used to check some "composed" credentials (like what happened with Okta last year) then maybe it's worth worrying about, no ?
Yeah you definitely should not be paying that much. Throw your NMI into https://www.energymadeeasy.gov.au/ and it'll show you the most cost effective option from your actual usage. I'm also in Sydney and pay 29c flat/ 18c secondary circuit
This is pretty cool, but demonstrates why google/apple maps make heavy use of bespoke models vs just the map data, as is demonstrated pretty well by the sydney opera house and harbour bridge
https://demo.f4map.com/#lat=-33.8564200&lon=151.2149210&zoom...
f4map does a pretty good job, although I'm not sure if they use some extra model here or just render it based on osm data. Sydney opera house seems pretty well mapped and I think you could get something like that from it.
As an Australian it's always a bit of a shock to see brand new European and American trains stopping at platforms no taller than a kerb, meaning you have to walk up steps.
I'd be very interested to see how much of a bottleneck boarding from the lower level of these trains is, in sydney we have double deckers where you board from the middle level from high platforms[1] and the stairs are already a flow limitation in the city section, I can't imagine how bad it would be with people going up two flights of stairs
