Very click baity and not good journalism imho. Starting with a "A GeForce RTX 4090 could be cracking your password at this moment." tag line only to later note:
> With bcrypt, the hashing times soared. While the GeForce RTX 4090 only took 59 minutes to crack an MD5 hash, the same graphics card would need 99 years.
It's 2024 and if your password is still being hashed with md5, the news are: Your password could have been cracked 10 or more years ago already. Nobody sane uses that anymore and bcrypt still stands the test.
And even worse, that's bcrypt with 32 iterations - a work factor of 5. Every Bcrypt implementation I've seen has a default work factor of 10 (1024 rounds), and people often use higher values that that.
So that 99 years is a massive underestimate for any actually secure password storage.
It doesn't work that way - and if it did - it's absolutely acceptable in most, if not all systems. A year to "break something" is absolutely considered secure in risk management of larger systems.
start using very high entropy passwords which contain just about all printable ascii characters, excluding whitespace.
If a computer cant guess it, it won't crack the hash, either.
Use a password manager and make those suckers 20-40 characters.
Use a master key that is just a super long phrase interleaved with special characters. Easy to remember. Like titles of books you like, plus authors, plus something only you know. Stuff like that.
I use a version of KeePass, with the actual file synced via syncthing to all devices plus a cloud.
One huge benefit of random session tokens is also that you can't include arbitrary metadata that is sent to the client.
Decoding JWTs of web apps can give you a lot of suprises like the account email address or even password being stored inside them. For devs that don't know the difference between signing and encrypting JWTs are a footgun and even for those that do it can be confusing. The specifications are also a hard read. A handful of RFCs where you don't really know which one to lookup. JWT, JWK, JWE, JWA, WTF? It seems to do everything at once, signing and encryption, symmetric and asymmetric, and the format is always quite similar!
On the other side, if you are able to avoid the many pitfalls, JWTs can be very useful in the right place when used properly. You could probably write an equally or more secure JSON based token format from scratch without that much effort by just keeping it simple and restrictive/opinionated, though.
Open Source Maintainers shouldn't judge the people trying to contribute, but the contributions. If the contribution is misguided or not good, it's their responsibility to reject it. On the other side, if the contributor's intention is to boost their resume, but the contribution is also good and an improvement, so be it! Good contributions are too rare to only select the ones done with selfless intentions...
As one communications book said (paraphrase): "Should is a word for the lazy. Eliminate it from your vocabulary."
> If the contribution is misguided or not good, it's their responsibility to reject it.
Arguably, they do not have a responsibility to even look at it. They definitely do not have a responsibility to accept/reject it.
All good rules fail when confronted with constraints. If a maintainer had infinite time and resources, your advice is good. Because they don't, utilizing heuristics is necessary. What the author is hinting at is being clear about turning away people seeking to boost their resume is a useful heuristic.
Same reason why employers reject people whose main goal of joining the company is to boost their resume.
If I'm an open source maintainer and I feel the contributor is an annoying twit, I find no problems in ignoring him altogether (i.e. implicitly rejecting his contributions). If you want to be an intermediary and take the time to judge his contributions, and report to me which ones are worth my time, I'll be happy to have you do it.
Judging by the Jia Tan situation, I think maintainers should judge contributors as well.
It’s the maintainer’s job to be defensive of their projects and prevent them from being abused. It’s not necessarily their job to build and foster a community.
This is one one of those things that sounds nice in theory, but falls down in practice, because in reality the overlap between "spammy junk" and "contributions done purely to boost resume" is very close to 1:1. I'm sure there's the odd exception, but it's rare.
So in practice "judging the contribution" and "judging the contributor" are identical.
They aren’t really. Even if the overlap was completely perfect and all spam contributions were the ones done to boost resume, you still shouldn’t judge the contributor for trying to boost their resume but judge the contribution by how useless and spammy it is.
The daily check ins require a photo upload. Of course people can cheat by uploading non-legitimate photos, or just lie, but for now we are maintaining the honor-system approach. We think this will work (and its working in the challenges we're currently running with people we don't know!) because the challenges are with small groups of people. If the groups were huge then it'd be way easier to blend in and cheat, but with smaller groups where you're building the connections, we hope that people find it less motivating to cheat.
Also, if we keep getting users, we will definitely keep improving the cheating detection mechanisms (using AI and other logic), and also adding features like reporting users, reputation scores, etc.!
I'd switch to passkeys immediately where possible, if Android/Google would allow third party password manager apps to provide and store them. Afaik they still want you to use the Google Password Manager, which is not an option for me.
3rd party passkey provider support is possible on Android if:
- You are using Android 14
- Your manufacturer has added support for it (e. g. Oppo and OnePlus still haven't)
- If you want to use them in chrome, you need to enable the experimental feature at chrome://flags , search for "passkeys" and enable the feature for 3rd party (for brave just replace "chrome" with "brave"
Even with that, support may still be a bit buggy, such as:
- Chrome displaying the "Google Password Manager" logo instead of your password manager's one
- The app/website not understanding properly how to implement them and sending wrong values / sometimes invalid payloads
But let's hope this technology gains massive adoption, proper support and can help non-technical users benefit from increased security at (almost) no cost.
You can use any passkey provider app. I work at Bitwarden and we’re building mobile passkeys for android right now. We can do the e2e sync, but if you want you can always self host Bitwarden server and just use our clients app.
The BitWarden passkey dialog irks me because it makes me click the passkey I want, even if I have exactly one. It would be better to have a feature where I could specify "always use this passkey and don't prompt", since that's what I need 99% of the time.
This has been annoying me as well: WebAuthN even provides metadata that lets authenticators know which credentials they're willing to accept, so at least in that case (usually the flows where you have to enter a username), auto-selection should be possible.
With discoverable credentials (which Passkeys by definition are), i.e. the flows where you don't even enter a username and the website learns it from the selected passkey, I don't think there's a way around a key selection process, but the UI can definitely be improved to distinguish the two.
Maybe something like "website XYZ is trying to verify your account 'username' – is that ok?" vs. "website XYZ wants to authenticate you – which passkey do you want to present to them (if any)"?
I'm already seeing Bitwarden as an option for Passkey authentication on iOS! Apparently the app already exposes itself to iOS as a WebAuthN backend (or the API is the same as that used for password managers).
Unfortunately that API doesn't seem to be wired to anything in the app yet, so selecting it inevitably fails.
> With bcrypt, the hashing times soared. While the GeForce RTX 4090 only took 59 minutes to crack an MD5 hash, the same graphics card would need 99 years.
It's 2024 and if your password is still being hashed with md5, the news are: Your password could have been cracked 10 or more years ago already. Nobody sane uses that anymore and bcrypt still stands the test.
reply