Post-Quantum Cryptography Comes to Windows Insiders and Linux.
@jadi This "#OpenBSD is secure!" claim always annoyed me a lot, mainly because it doesn't tell anything: #Security in IT can only ever be defined in a context of #threat models. Without that, it's meaningless. Somewhat recently, I discovered this:
I should warn it uses some sarcasm and other confrontative language in some parts, unfortunately. But it seems to be a pretty professional analysis and assessment of (mostly) the "mitigations" OpenBSD provides in an attempt to counter "typical" attacks by at least making them harder.
I should also add that I consider this a very interesting and helpful read, and still consider OpenBSD a great project that came up with lots of great stuff (I recently used their #bcrypt code after doing some research on password hashing, for example). And I don't agree with every single criticism on that page either. I just think it's important to build assessments whether something "is secure" on a serious analytical foundation.
I need some advise: Is there a good portable and free (really free, not GPL!) #implementation of #bcrypt in #C around?
There's #OpenBSD source I could use, but integrating that would probably be quite a hassle...
Background: I want to start creating a second credential checker for #swad using files. And it probably makes sense to support a sane subset of #Apache's #htpasswd format here. Looking at the docs:
https://httpd.apache.org/docs/current/misc/password_encryptions.html
... the "sane subset" seems to be just bcrypt. *MAYBE* also this apache-specific flavor of "iterated" MD5, although that sounds a bit fishy ...
IMO we need to stop coming up with algorithms to securely store "derivatives" of typically weak passwords, as
IT WILL FAIL.
From https://www.akkadia.org/drepper/SHA-crypt.txt:
❝
In addition, the produced output for [...] MD5 has a short length which makes it possible to construct rainbow tables.
❞
Please correct me if I'm wrong, but even in 2025 suggesting that a rainbow table is feasible for (lets cut a few bits for MD5 weaknesses) random numbers of 120 bits in length is BS (in order to create FUD).
If I'm right about that, the least bad thing to do is:
1) Everyone should use a password manager (pwmgr) because people simply do not have the ability to come up with a sufficiently strong password that is *unique for each account*, let alone for multiple accounts (sometimes hundreds), to remember them absolutely error-free, and to recall which password was chosen for which account.
Note: IMO password *reuse* currently is the biggest threat. Entering a reused password on a fake (phishing) website may have devastating consequences, because (when a password is reused for multiple accounts) chances are that ALL those accounts are compromised. Note that the complexity and uniqueness of the password are IRELLEVANT. And, what KDF is used on the server, is IRRELEVANT as well.
2) Let the pwngr generate a (cryptographically) random password, as long and with as much entropy as allowed by the server.
3) Use a strong master password and NEVER forget it (typical beginner failure).
4) Make sure the database is backed up in more than one place, and make a backup after each modification.
5) Make sure that the device the password mamager is used on, *never* gets compromised.
6) Double check that https:// is used. Better, make sure to use a browser that blocks http:// connections and warns you (Safari on iOS/iPadOS now supports "Not Secure Connection Warning"). In all browsers such a setting is OFF by default: ENABLE IT!
7) On a mobile device: use "Autofill". The OS then transfers the domain name (shown in the browser's address bar) to the pwmgr. If a matching domain name is *not found* in the pw database, assume that you're on a (fake) phishing website! In that case: DO NOT ATTEMPT TO LOG IN by looking up credentials yourself. Reasons for 7, two examples:
----
fake: circle-ci·com
real: circleci.com
----
fake: lîdl.be
real: lidl.be
----
If people would follow this advice (which is not just mine), even MD5 for storing a one-way derivative of the password on the server would be fine.
HOWEVER: don't use MD5 - because "never use MD5 for whatever" is easier to remember than "don't use MD5 if preimage attacks are possible".
P.S. I'm not a cryptographer (although I'm quite interested in the matter).
"Hallo, ich habe mein Passwort vergessen. Könnt ihr mir mein altes zuschicken?"
Nein. Und das ist auch gut so. 
"What Okta Bcrypt incident can teach us about designing better APIs"
https://n0rdy.foo/posts/20250121/okta-bcrypt-lessons-for-better-apis/
@cubeos : salts sind meist nützlos.
Aber zuerst: wieviele Accounts hast du? Für die meiste Menschen ist es unmöglich viele starke Passworter im Kopf zu speichern und zu erinnern. Nur deshalb: Password-Manager!
Salz: moderne NVidia GPU''s sind so schell dass man keine Rainbow Tables braucht. Wenn den Attacker Hash + Salz kennt, gehts los ("Pepper" würde helfen wenn nicht gestohlen/kopieert).
Screenshot aus https://gist.github.com/Chick3nman/32e662a5bb63bc4f51b847bb422222fd.
So ... due to an early obsession with historical BSD hashes ... I have significantly more bcrypt hashrate-per-watt cracking capacity than most solo shops. For bcrypt cost 12, it's about 34Kh/s straight wordlist -- the equivalent of about 17 4090s -- at only 1100W (these old Bitcoin FPGAs are very efficient for bcrypt specifically). And this capacity is intermittently idle, which is kinda a shame.
I haven't really put it out there as something I can help with if needed (outside of the Hashcat team). So ... feel free to ping me if you need bcrypts cracked/audited!
(Reasonable rates, but note that I do have a pretty firmly high bar for provenance / proof of authorization)
(Rat's nest of USB has been cleaned up a bit )
After spending a few days debugging a performance issue in a web app, it turned out that the problem happens when we have sudden bursts of highly-concurrent requests all going through #bcrypt for token validation
Hey, @nielsprovos - if I may impose ... I saw someone asking why the minimum bcrypt cost is 4, and realized that I had no idea(!) So I spent some time with your USENIX presentation[1] and the code[2], but couldn't see an immediate answer, other than an uninformed guess that F starts with four arrays. What's the real answer?
Are your passwords in the green?
https://www.hivesystems.com/blog/are-your-passwords-in-the-green
Really stop using MD5 already for passwords.
New Password Cracking Analysis Targets #Bcrypt
Bcrypt is the "go to" algorithm for hashing for a lot of things because it's what I like to call "secure enough."
But considering this study found that 1) any password under 7 characters could be cracked in hours and 2) "weak" 11-character #passwords take ~10 hours to crack.
Will it be the new #MD5 in a few years?
#cybersecurity #security #cryptography
https://www.securityweek.com/new-password-cracking-analysis-targets-bcrypt/
Essentially, distro developers are firefighters, putting out fires made by careless upstreams.
What I've wasted time on, today:
- making the non-standalone test suite of #Hatchling (sigh) work without #UV again, so that a critical build dependency of a growing number of #Python packages could be tested everywhere
https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=cc6e54e1df5e0802198c793f39107a9028b8698f
https://bugs.gentoo.org/930662
- fixing effectively dead (but with a promise of revival) #PassLib not to break random stuff via printing warnings when using newer #BCrypt versions
https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=c1e015b65b74283a51893672739c5e4784b95273
https://bugs.gentoo.org/925289
- hacking the test suite of #ImageIO work using an offline copy of test data, rather than cloning its git repository at the beginning of tests
https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=77ff4bc09d68067f2c635d43d446f308990e0873
I really wish people would consider donating to distro developers more often, rather than to projects that create this thankless work for us.
This was interesting, building hardware like backblaze but old using old second hand FPGA's from the crypto world to get good performance on bcrypt cracking
https://scatteredsecrets.medium.com/bcrypt-password-cracking-extremely-slow-not-if-you-are-using-hundreds-of-fpgas-7ae42e3272f6
I wonder who maintains `passlib` these days? Seems it does not play well with `bcrypt`.
Found this out bringing up a deployment with Ansible, since it uses `passlib` to support lots of hashes, and parts of our stack use `bcrypt` hashing. (Yes, I'd prefer `scrypt` or `argon2id`, but apparently I'm clueless about these things.)
Nice little land mine to go bang on a Friday.
Indeed! I know I'm preaching to the choir, but for those playing along at home:
Selecting a bcrypt cost falls into two classes of use case:
individual UX (personal/per-user), and
aggregate UX (for non-trivial numbers of concurrent auths and/or thundering herds / reauth storms).
For self-contained / standalone, and smaller user populations, the first case is primary. Admins can maximize bcrypt cost based solely on whether their (small group of users) can tolerate X milliseconds of delay - without regard to how users will impact each other. Bcrypt cost 13 - or even higher - can be feasible here.
In the second case (non-trivial user populations) - the game is to balance both use cases - individual UX, but adding in auth-per-second statistics, thundering herd scenarios, sufficient hardware budget to support robust user password protection, etc.
And if you're maintaining a general framework that needs to support either use case ... the best thing for the ecosystem may be to guide the downstream admin towards the best choice for them (explanatory comment in a config file, interactive + informed selection during an install, etc.).
The nice thing about most bcrypt implementations is that they're forward- and backward-compatible, supporting multiple costs simultaneously (with all new users, and all password resets, following the new default). So for larger user populations, the admin can shape their aggregate load over time, to manage performance "forward" to increase bcrypt cost apace with CPU speed increases, to keep per-auth speed as close to that "500ms to 1 second" UX window as possible over time.
@tychotithonus @valorin Voting for the "Increasing the default #BCrypt cost" #PHP #RFC is now open:
@valorin This might be of interest to you for Laravel, which appears to also use `10` as the default value for BCrypt costs:
