#bcrypt — Public Fediverse posts

أطلق مشروع Wine الإصدار الجديد 11.15 الذي يقدم ميزات تقنية هامة لتعزيز التوافق مع بيئات ويندوز المختلفة. يتضمن هذا التحديث دعم المصادقة المحلية NTLM وإضافة خوارزميات KDF جديدة في BCrypt، بالإضافة إلى دعم بناء ARM64EC في وضع Mingw. كما ركز المطورون على تحسين استقرار النظام من خلال إصلاح 41 خطأً برمجياً، مما يضمن تجربة تشغيل أفضل لمجموعة واسعة من التطبيقات والأدوات البرمجية المتنوعة التي يعتمد عليها المستخدمون في أعمالهم اليومية بكفاءة عالية.

#Wine #Windows #BCrypt

Безопасное хранение паролей: соли, перцы и выбор алгоритма

Выбираете алгоритм хеширования паролей — берёте bcrypt, потому что все берут bcrypt, ставите rounds=10, потому что так в туториале, и идёте дальше. Разбираем, почему это может быть ошибкой, чем отличаются Argon2, scrypt и PBKDF2, и как правильно настроить каждый из них.

https://habr.com/ru/articles/1051800/

#хеширование_паролей #bcrypt #argon2 #криптография #информационная_безопасность #аутентификация #rainbow_tables #соль #PBKDF2 #scrypt

Since Wordpress v6.8, the default hash func produces a custom bcrypt hash: $wp$2y$10$...

More info on this custom algo, how it uses hmac-sha384, and how to crack them with hashcat.

https://forum.hashpwn.net/post/4205

#wordpress #bcrypt #wpbcrypt #hashcracking #hashpwn #hashgen #hashcat

Hoy aprendí sobre el algoritmo de hash #bcrypt, basado en el cifrador de bloques #Blowfish, revisando un artículo de @andrea_navarro sobre extensiones de #Flask... particularmente sobre las extensiones de seguridad.

Y acabo de descubrir que es uno de los algoritmos soportados para la creación de passwords en GNU/Linux :D

Habrá que hacer algunos experimentos.

#gnu #linux #cryptography #criptografía #ciberseguridad #infosec #encrypt #hash #python #flask

Hoy aprendí sobre el algoritmo de hash #bcrypt, basado en el cifrador de bloques #Blowfish, revisando un artículo de @andrea_navarro sobre extensiones de #Flask... particularmente sobre las extensiones de seguridad.

Y acabo de descubrir que es uno de los algoritmos soportados para la creación de passwords en GNU/Linux :D

Habrá que hacer algunos experimentos.

#gnu #linux #cryptography #criptografía #ciberseguridad #infosec #encrypt #hash #python #flask

#4 👥 Leverage built-in authentication with #Breeze, #Fortify or #Jetstream
🗝️ Store passwords securely using #Bcrypt or #Argon2 hashing algorithms
🔑 Secure environment variables and force #HTTPS in production environments

#4 👥 Leverage built-in authentication with #Breeze, #Fortify or #Jetstream
🗝️ Store passwords securely using #Bcrypt or #Argon2 hashing algorithms
🔑 Secure environment variables and force #HTTPS in production environments

@thinkberg this page is gold. Pitty that the #bcrypt one doesn't have a reference

@thinkberg this page is gold. Pitty that the #bcrypt one doesn't have a reference

Post-Quantum Cryptography Comes to Windows Insiders and Linux.

https://techcommunity.microsoft.com/blog/microsoft-security-blog/post-quantum-cryptography-comes-to-windows-insiders-and-linux/4413803

#win32 #windows #ncrypt #bcrypt #cryptography #encryption #linux

Post-Quantum Cryptography Comes to Windows Insiders and Linux.

https://techcommunity.microsoft.com/blog/microsoft-security-blog/post-quantum-cryptography-comes-to-windows-insiders-and-linux/4413803

#win32 #windows #ncrypt #bcrypt #cryptography #encryption #linux

This is... interesting. Apparently bcrypt truncates user provided passwords at 72 byte marker. I guess one way can be to "prehash" the password with a HMAC as suggested here:

https://soatok.blog/2024/11/27/beyond-bcrypt/

The other (simpler) approach would be to, like Go's x/crypto/bcrypt, just reject all user provided passwords > 72 bytes. It is not *great*, but it works and fails "safe". Now one wonders *why* this is not the default behavior of PHP's password_hash function...

#password #bcrypt #php

New version of #hashgen published.

Changelog:
v1.1.0; 2025-03-19
added modes: #base58, #argon2id, #bcrypt w/custom cost factor

https://forum.hashpwn.net/post/89

#hashgenerator #hashcracking #hashcat #hashpwn #cyclone #golang

#TalesFromSupport

"Hallo, ich habe mein Passwort vergessen. Könnt ihr mir mein altes zuschicken?"

Nein. Und das ist auch gut so. 😅

#Passwort #Hash #bcrypt

#TalesFromSupport

"Hallo, ich habe mein Passwort vergessen. Könnt ihr mir mein altes zuschicken?"

Nein. Und das ist auch gut so. 😅

#Passwort #Hash #bcrypt

„The #bcrypt password hashing function should only be used for password storage in legacy systems where #Argon2 and scrypt are not available.“
https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html#bcrypt #security #owasp

„The #bcrypt password hashing function should only be used for password storage in legacy systems where #Argon2 and scrypt are not available.“
https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html#bcrypt #security #owasp

Hashing Passwords: Why MD5 and SHA Are Outdated, and Why You Should Use Scrypt or Bcrypt

#bcrypt #md5 #password #scrypt #sha

https://dev.to/lovestaco/hashing-passwords-why-md5-and-sha-are-outdated-and-why-you-should-use-scrypt-or-bcrypt-48p2

Hashing Passwords: Why MD5 and SHA Are Outdated, and Why You Should Use Scrypt or Bcrypt

#bcrypt #md5 #password #scrypt #sha

https://dev.to/lovestaco/hashing-passwords-why-md5-and-sha-are-outdated-and-why-you-should-use-scrypt-or-bcrypt-48p2

"What Okta Bcrypt incident can teach us about designing better APIs"

https://n0rdy.foo/posts/20250121/okta-bcrypt-lessons-for-better-apis/

#security #bcrypt #apis #okta #cybersecurity

"What Okta Bcrypt incident can teach us about designing better APIs"

https://n0rdy.foo/posts/20250121/okta-bcrypt-lessons-for-better-apis/

#security #bcrypt #apis #okta #cybersecurity

What #Okta #Bcrypt incident can teach us about designing better #APIs

https://itnext.io/what-okta-bcrypt-incident-can-teach-us-about-designing-better-apis-b87efe2bb830

What #Okta #Bcrypt incident can teach us about designing better #APIs

https://itnext.io/what-okta-bcrypt-incident-can-teach-us-about-designing-better-apis-b87efe2bb830

Beyond Bcrypt

In 2010, Coda Hale wrote How To Safely Store A Password which began with the repeated phrase, “Use bcrypt”, where the word bcrypt was linked to a different implementation for various programming languages.

This had two effects on the technology blogosphere at the time:

1. It convinced a lot of people that bcrypt was the right answer for storing a password.
2. It created a meme for how technology bloggers recommend specific cryptographic algorithms when they want attention from Hacker News.

At the time, it was great advice!

In 2010, bcrypt was the only clearly good answer for password hashing in most programming languages.

In the intervening almost fifteen years, we’ve learned a lot more about passwords, password cracking, authentication mechanism beyond passwords, and password-based cryptography.

If you haven’t already read my previous post about password-based cryptography, you may want to give that one a once-over before you continue.

But we’ve also learned a lot more about bcrypt, its limitations, the various footguns involved with using it in practice, and even some cool shit you can build with it.

In light of a recent discussion about switching WordPress’s password hashing algorithm from PHPass (which is based on MD5) to bcrypt, I feel now is the perfect time to dive into this algorithm and its implications on real-world cryptography.

Understanding Bcrypt in 2024

Bcrypt is a password hashing function, but not a password KDF or general-purpose cryptographic hash function.

If you’re using a sane password storage API, such as PHP’s password API, you don’t even need to think about salting your passwords, securely verifying passwords, or handling weird error conditions. Instead, you only need concern yourself with the “cost” factor, which exponentially increases the runtime of the algorithm.

There’s just one problem: bcrypt silently truncates after 72 characters (or rather, bytes, if you’re pedantic and assume non-ASCII passwords, such as emoji).

Here’s a quick script you can run yourself to test this:

<?php$example1 = str_repeat('A', 72);$example2 = $example1 . 'B';$hash = password_hash($example1, PASSWORD_BCRYPT);var_dump(password_verify($example2, $hash));

This may sound ludicrous (“who uses 72 character passwords anyway?”) until you see security advisories like this recent one from Okta.

The Bcrypt algorithm was used to generate the cache key where we hash a combined string of userId + username + password. Under a specific set of conditions, listed below, this could allow users to authenticate by providing the username with the stored cache key of a previous successful authentication.

(…)

• The username is 52 characters or longer

The other thing to consider is that many people use passphrases, such as those generated from Diceware, which produce longer strings with less entropy per character.

If you use bcrypt as-is, you will inevitably run into this truncation at some point.

“Let’s pre-hash passwords!”

In response to this limitation, many developers will suggest pre-hashing the password with a general purpose cryptographic hash function, such as SHA-256.

And so, in pursuit of a way to avoid one footgun, developers introduced two more.

Truncation on NUL Bytes

If you use the raw binary output of a hash function as your password hash, be aware that bcrypt will truncate on NUL (0x00) bytes.

With respect to the WordPress issue linked above, the default for PHP’s hashing API is to output hexadecimal characters.

This is a bit wasteful. Base64 is preferable, although any isomorphism of the raw hash output that doesn’t include a 0x00 byte is safe from truncation.

Hash Shucking

When a system performs a migration from a cryptographic hash function (e.g., MD5) to bcrypt, they typically choose to re-hash the existing hash with bcrypt.

Because users typically reuse passwords, you can often take the fast, unsalted hashes from another breach and use it as your password dictionary for bcrypt.

If then you succeed in verifying the bcrypt password for a fast hash, you can then plug the fast hash into software like Hashcat, and then crack the actual password at a much faster rate (tens of billions of candidates/second, versus thousands per second).

This technique is called hash shucking (YouTube link).

You can avoid hash shucking by using HMAC with a static key–either universal for all deployments of your software, or unique per application.

It doesn’t really matter which you choose; all you really need from it is domain separation from naked hashes.

I frequently see this referred to as “peppering”, but the term “pepper” isn’t rigidly defined anywhere.

One benefit of using a per-application HMAC secret does make your hashes harder to crack if you don’t know this secret.

For balance, one downside is that your hashes are no longer portable across applications without managing this static key.

Disarming Bcrypt’s Footguns

Altogether, it’s quite straightforward to avoid bcrypt’s footguns, as I had recommended to WordPress last week.

1. Pre-hash with HMAC-SHA512.
2. Ensure the output of step 1 is base64-encoded.
3. Pass the output of step 2 to PHP’s password API.

Easy, straightforward, and uncontroversial. Right?

Objections to Bcrypt Disarmament

The linked discussion was tedious, so I will briefly describe the objections raised to my suggestion.

1. This is “rolling our own crypto”.
   • Answer: No, it’s a well-understood pattern that’s been discussed in the PHP community for well over a decade.
2. Passwords over 72 characters are rare and not worthy of our consideration.
   • Answer: No, this has bit people in unexpected ways before (see: Okta).

     When you develop a popular CMS, library, or framework, you cannot possibly know all the ways that your software will be used by others. It’s almost always better to be misuse-resistant.

3. Pre-hashing introduces a Denial-of-Service attack risk.
   • Answer: No. Bcrypt with a cost factor of 10 is about 100,000 times as expensive as SHA2.
4. This introduces a risk of hash shucking.
   • As demonstrated above, HMAC doesn’t suffer this problem (assuming the key is reasonably selected).
5. Base64 encoding reduces entropy.
   • Answer: No, it’s isomorphic.
6. Base64 with the 72 character truncation reduces entropy.
   • Answer: We’re still truncating SHA-512 to more than 256 bits of its output, so this doesn’t actually matter for any practical security reason.
7. This would necessitate a special prefix (e.g. $2w$) to distinguish disarmed bcrypt from vanilla bcrypt that PHP’s password API wouldn’t know what to do with.
   • This is a trivial concern, for which the fix is also trivial:
     After password_hash(), modify the prefix with a marker to indicate pre-hashing.
     Before password_verify(), swap the original prefix back in.

There were some other weird arguments (such as “Bcrypt is approved by NIST for FIPS”, which is just plain false).

Why Bcrypt Truncating SHA-512 Doesn’t Matter

If you have a random secret key, HMAC-SHA-512 is a secure pseudorandom function that you can treat as a Random Oracle.

Because it’s HMAC, you don’t have to worry about Length Extension Attacks at all. Therefore, the best known attack strategy is to produce a collision.

The raw binary output of SHA-512 is 64 characters, but may contain NUL characters (which would truncate the hash). To avoid this, we base64-encode the output.

When you base64-encode a SHA-512 hash, the output is 88 characters (due to base64 padding). This is longer than the 72 characters supported by bcrypt, so it will truncate silently after 72 characters.

This is still secure, but to prove this, I need to use math.

First, let’s assume you’re working with an extremely secure, high-entropy password, and might be negatively impacted by this truncation. How bad is the damage in this extreme case?

There are 64 possible characters in the base64 alphabet. That’s tautology, after all.

If you have a string of length 72, for which each character can be one of 64 values, you can represent the total probability space of possible strings as .

If you know that , you can do a little bit of arithmetic and discover this quantity equal to .

As I discussed in my deep dive on the birthday bound, you can take the cube root of this number to find what I call the Optimal Birthday Bound.

This works out to samples in order to find a probability of a single collision.

This simply isn’t going to happen in our lifetimes.

The real concern is the entropy of the actual password, not losing a few bits from a truncated hash.

After all, even though the outputs of HMAC-SHA512 are indistinguishable from random when you don’t know the HMAC key, the input selection is entirely based on the (probably relatively easy-to-guess) password.

“Why not just use Argon2 or Scrypt?”

Argon2 and scrypt don’t have the bcrypt footguns. You can hash passwords of arbitrary length and not care about NUL characters. They’re great algorithms.

Several people involved in the Password Hashing Competition (that selected Argon2 as its winner) have since lamented the emphasis on memory-hardness over cache-hardness. Cache-hardness is more important for short run-times (i.e., password-based authentication), while memory-hardness is more important for longer run-times (i.e., key derivation).

As Sc00bz explains in the GitHub readme for his bscrypt project:

Cache hard algorithms are better than memory hard algorithms at shorter run times. Basically cache hard algorithms forces GPUs to use 1/4 to 1/16 of the memory bandwidth because of the large bus width (commonly 256 to 1024 bits). Another way to look at it is memory transactions vs bandwidth. Also the low latency of L2 cache on CPUs and the 8 parallel look ups let’s us make a lot of random reads. With memory hard algorithms, there is a point where doubling the memory quarters a GPU attacker’s speed. There then is a point at which a memory hard algorithm will overtake a cache hard algorithm. Cache hard algorithms don’t care that GPUs will get ~100% utilization of memory transactions because it’s already very limiting.

Ironically, bcrypt is cache-hard, while scrypt and the flavors of Argon2 that most people use are not.

Most of my peers just care that you use a password hashing algorithm at all. They don’t particularly care which. The bigger, and more common, vulnerability is not using one of them in the first place.

I’m mostly in agreement with them, but I would prefer that anyone that chooses bcrypt takes steps to disarm its footguns.

Turning Bcrypt Into a KDF

Earlier, I noted that bcrypt is not a password KDF. That doesn’t mean you can’t make one out of bcrypt. Ryan Castellucci is an amazing hacker; they managed to do just that.

To understand why this is difficult, and why Ryan’s hack works, you need to understand what bcrypt actually is.

Bcrypt is a relatively simple algorithm at its heart:

1. Run the Blowfish key schedule, several times, over both the password and salt.
2. Encrypt the string "OrpheanBeholderScryDoubt" 64 times in ECB mode using the expanded key from step 1.

Most of the heavy work in bcrypt is actually done in the key schedule; the encryption of three blocks (remember, Blowfish is a 64-bit block cipher) just ensures you need the correct resultant key from the key schedule.

“So how do you get an encryption key out of bcrypt?”

It’s simple: we, uh, hash the S-box.

static void BF_kwk(struct BF_data *data, uint8_t kwk[BLAKE2B_KEYBYTES]) {  BF_word *S = (BF_word *)data->ctx.S;  BF_htobe(S, 4*256);  // it should not be possible for this to fail...  int ret = blake2b_simple(kwk, BLAKE2B_KEYBYTES, S, sizeof(BF_word)*4*256);  assert(ret == 0);  BF_betoh(S, 4*256);}

Using BLAKE2b to hash the S-box from the final Blowfish key expansion yields a key-wrapping key that can be used to encrypt whatever data is being protected.

The only feasible way to recover this key is to provide the correct password and salt to arrive at the same key schedule.

Any attack against the selection of S implies a cryptographic weakness in bcrypt, too. (I’ve already recommended domain separation in a GitHub issue.)

It’s worth remembering that Ryan’s design is a proof-of-concept, not a peer-reviewed design ready for production. Still, it’s a cool hack.

It’s also not the first of its kind (thanks, Damien Miller).

If anyone was actually considering using this design, first, they should wait until it’s been adequately studied. Do not pass Go, do not collect $200.

Additionally, the output of the BLAKE2b hash should be used as the input keying material for, e.g., HKDF. This lets you split the password-based key into multiple application-specific sub-keys without running the password KDF again for each derived key.

Wrapping Up

Although bcrypt is still an excellent cache-hard password hashing function suitable for interactive logins, it does have corner cases that sometimes cause vulnerabilities in applications that misuse it.

If you’re going to use bcrypt, make sure you use bcrypt in line with my recommendations to WordPress: HMAC-SHA-512, base64 encode, then bcrypt.

Here’s a quick proof-of-concept for PHP software:

<?phpdeclare(strict_types=1);class SafeBcryptWrapperPoC{  private $staticKey;  private $cost = 12;  public function __construct(    #[\SensitiveParameter]    string $staticKey,    int $cost = 12  ) {    $this->staticKey = $staticKey;    $this->cost = $cost;  }    /**   * Generate password hashes here   */  public function hash(    #[\SensitiveParameter]    string $password  ): string {    return \password_hash(      $this->prehash($password),      PASSWORD_BCRYPT,      ['cost' => $this->cost]    );  }  /**   * Verify password here   */  public function verify(    #[\SensitiveParameter]    string $password,    #[\SensitiveParameter]    string $hash  ): bool {    return \password_verify(      $this->prehash($password),      $hash    );  }  /**   * Pre-hashing with HMAC-SHA-512 here   *   * Note that this prefers the libsodium base64 code, since   * it's implemented in constant-time   */  private function prehash(    #[\SensitiveParameter]    string $password  ): string {    return \sodium_bin2base64(      \hash_hmac('sha512', $password, $this->staticKey, true),      \SODIUM_BASE64_VARIANT_ORIGINAL_NO_PADDING    );  }}

You can see a modified version of this proof-of-concept on 3v4l, which includes the same demo from the top of this blog post to demonstrate the 72-character truncation bug.

If you’re already using bcrypt in production, you should be cautious with adding this pre-hashing alternative. Having vanilla bcrypt and non-vanilla bcrypt side-by-side could introduce problems that need to be thoroughly considered.

I can safely recommend it to WordPress because they weren’t using bcrypt before. Most of the people reading this are probably not working on the WordPress core.

Addendum (2024-11-28)

More of the WordPress team has chimed in to signal support for vanilla bcrypt, rather than disarming the bcrypt footgun.

The reason?

That would result in maximum compatibility for existing WordPress users who use the Password hashes outside of WordPress, while also not introducing yet-another-custom-hash into the web where it’s not overly obviously necessary, but while still gaining the bcrypt advantages for where it’s possible.

dd32

The hesitance to introduce a custom hash construction is understandable, but the goal I emphasized with bold text is weird and not a reasonable goal for any password storage system.

It’s true that the overwhelming non-WordPress code written in PHP is just using the password hashing API. But that means they aren’t compatible with WordPress today. PHP’s password hashing API doesn’t implement phpass, after all.

In addition to being scope creep for a secure password storage strategy, it’s kind of a bonkers design constraint to expect password hashes be portable. Why are you intentionally exposing hashes unnecessarily?

At this point, it’s overwhelmingly likely that WordPress will choose to not disarm the bcrypt footguns, and will just ship it.

That’s certainly not the worst outcome, but I do object to arriving there for stupid reasons, and that GitHub thread is full of stupid reasons and misinformation.

The most potent source of misinformation also barked orders at me and then tried to dismiss my technical arguments as the concerns of “the hobbyist community”, which was a great addition to my LinkedIn profile.

If WordPress’s choice turns out to be a mistake–that is to say, that their decision for vanilla bcrypt introduces a vulnerability in a plugin or theme that uses their password hashing API for, I dunno, API keys?–at least I can say I tried.

Additionally, WordPress cannot say they didn’t know the risk existed, especially in a courtroom, since me informing them of it is so thoroughly documented (and archived).

Here’s to hoping the risk never actually manifests. Saying “I told you so” is more bitter than sweet in security. Happy Thanksgiving.

Header image: Art by Jim and CMYKat; a collage of some DEFCON photos, as well as Creative Commons photos of Bruce Schneier (inventor of the Blowfish block cipher) and Niels Provos (co-designer of bcrypt, which is based on Blowfish).

#bcrypt #cryptography #passwordHashing #passwords #SecurityGuidance

How To Make A WireGuard Easy (wg-easy) VPN Server With Web-Based Admin UI On An Ubuntu Linux VPS https://youtu.be/i-ezlKq7V54 #Websplaining #WireGuard #wgeasy #WireGuardEasy #VPN #WireGuardVPN #VirtualPrivateNetwork #VPS #VirtualPrivateServer #Docker #CloudServer #Ubuntu #Linux #UbuntuLinux #Bcrypt #PasswordHash #PasswordHasher #GeneratePasswordHash #WebUI #WebBasedUI #UserInterface #AdminUI #UI #Server

Hey Internet Archive, not the best PR stunt :) #hibp #bcrypt

Zhackowano Internet Archive. Wyciek ~31 milionów rekordów z danymi logowania

Na razie nie wiadomo jak doszło do wycieku, w każdym razie ktoś udostępnił ~6GB plik zawierający dane logowania (w szczególności hasła bcrypt, e-maile). Najwyraźniej atakującym udało się też uzyskać dostęp do modyfikacji treści samego serwisu web.archive.org – wg relacji odwiedzający widzieli taki popup w JavaScript: I rzeczywiście, dane te już...

#WBiegu #Awareness #Bcrypt #Wyciek

https://sekurak.pl/zhackowano-internet-archive-wyciek-31-milionow-rekordow-z-danymi-logowania/

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 😅)

#bcrypt #PasswordCracking #hashing

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 😅)

#bcrypt #PasswordCracking #hashing

Laravel ist lustig.

Bei mir baut er TailwindCSS anders (mit `!important`) als bei den anderen. Sei's drum.

Meine überarbeitete Seite wurde akzeptiert und ich habe mich an die Login-Seite gemacht. Mit Browser-Test.

Ich muss sagen, #Laravel enttäuscht mich da.
Von Haus aus muss ein Passwort acht Zeichen oder länger sein. Es wird mit #bcrypt verschlüsselt gespeichert.

Zum einen sind damit Passwörter wie „01234567890“ okay (aber in Sekunden erraten), zum anderen ist der Algorithmus nur noch für Legacy-Systeme zu empfehlen (Argon oder scrypt wären laut OWASP Cheatsheet zu empfehlen) und zum Dritten konnte ich weder etwas zu Salt noch zu Pepper lesen.

Standardeinstellungen sind so wichtig und gerade Frameworks sehe ich da in der Verantwortung.

Aber das ist noch nicht alles.

Als ich den Browsertest für das Login geschrieben habe, musste ich vorher eine Registrierung durchlaufen. Das führt zum Dashboard.
Das Logout ist in einem Hamburgermenü versteckt und hat ein Anchor-Element, welches per JavaScript ein Formular absendet. Die /logout-Route akzeptiert keine GET-Anfragen.
Semantisch eine Vollkatastrophe und seit mindestens vier Jahren Teil der Standard-Austattung!

Das zugehörige Repo hat keinen Issue-Tracker.

Welchen Kanal nutzt die Laravel-Community für Verbesserungsvorschläge?

#Python Friday #227: Hash a Password With #Bcrypt #security #FastAPI

https://improveandrepeat.com/2024/05/python-friday-227-hash-a-password-with-bcrypt/

#Python Friday #227: Hash a Password With #Bcrypt #security #FastAPI

https://improveandrepeat.com/2024/05/python-friday-227-hash-a-password-with-bcrypt/

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?

1. https://www.usenix.org/legacy/publications/library/proceedings/usenix99/full_papers/provos/provos_html/

2. https://github.com/openbsd/src/blob/master/lib/libc/crypt/bcrypt.c

#bcrypt

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?

1. https://www.usenix.org/legacy/publications/library/proceedings/usenix99/full_papers/provos/provos_html/

2. https://github.com/openbsd/src/blob/master/lib/libc/crypt/bcrypt.c

#bcrypt

Are your passwords in the green?

https://www.hivesystems.com/blog/are-your-passwords-in-the-green

Really stop using MD5 already for passwords.

#Security #Passwords #Hashing #MD5 #Bcrypt

Are your passwords in the green?

https://www.hivesystems.com/blog/are-your-passwords-in-the-green

Really stop using MD5 already for passwords.

#Security #Passwords #Hashing #MD5 #Bcrypt

📬 Hive Systems: Trotz Bcrypt-Verschlüsselung keine Passort-Sicherheit
#Datenschutz #ITSicherheit #Studie #AlexNette #Bcrypt #BlowfishVerschlüsselung #BruteForce #CoreyNeskey #haveibeenpwned #HiveSystems #NVIDIAGeForceRTX4090GPUs #Passwort https://sc.tarnkappe.info/f1ed00

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.

#Gentoo

Brute force password cracking takes longer than ever, according to Hive Systems' latest audit. #PasswordCracking #BruteForceAttacks #HiveSystems #PasswordHashing #CyberSecurity #bcrypt #MD5
thttps://www.blogger.com/blog/post/edit/2393063772924596666/7373948891148112675

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

#bcrypt #bruteforce #fpga #infosec

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.

https://bugs.gentoo.org/925289

#python #passlib #bcrypt #ansible

@valorin

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:

1. individual UX (personal/per-user), and

2. 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.

#bcrypt #passwords #passwordhashing

@timwolla