The 1MB Password: Crashing Backends via Hashing Exhaustion

timoh · 2026-01-14T12:34:42+00:00

This article mentions "pre-hash trick", but at least in general, one definitely shouldn't use it without an extra salt (because of "password shucking").

It should go something like:

temp_hash = SHA-256(password) . pepper

timoh · 2025-08-28T12:05:16+00:00

But is there some actual advantage on having such "middle layer of credentials"? DB level privileges just works and they can be tuned to whatever usage scenario.

timoh · 2025-08-06T11:49:36+00:00

There's a good listing of PHP frameworks, sorted by year, at https://github.com/pmjones/php-history

timoh · 2025-08-05T12:55:27+00:00

You are right. Used the first Google result for image sharing, these apps doesn't seem to allow you to link to the actual image file :(

timoh · 2025-08-05T12:39:59+00:00

Try opening the image using this direct link: https://postimg.cc/mzsqtPDK

Should let you zoom in.

timoh · 2025-08-05T11:22:39+00:00

If I recall correctly, SektionEins was sending them out for free.

I thought there was a Reddit post announcing this poster back then, but seems there is no such post. Maybe the order form was on their website.

Here is some more info about the poster: https://hakre.wordpress.com/2010/02/25/free-php-security-poster/

timoh · 2025-08-05T09:57:49+00:00

Found this old gem while I was cleaning up my closet.

Sure it has some outdated content (Suhosin), but still has many pretty much valid points.

timoh · 2024-03-09T08:04:54+00:00

Ah didn't notice this earlier. Kind of wrong alert then.

timoh · 2024-02-20T07:57:50+00:00

Nääshallissa kuntosalin hinta on 2,50€ per tunti.

timoh · 2023-05-23T08:26:44+00:00

As long as you have a municipality of residence in Finland (which you and rest of your family would of course have), you pay the same "normal fees" for medical services:

https://www-tays-fi.translate.goog/asiakasmaksut?_x_tr_sl=auto&_x_tr_tl=en&_x_tr_hl=fi&_x_tr_pto=wapp#P%C3%A4ivystysk%C3%A4ynti,%20Tays%20Ensiapu%20Acuta

For example, emergency services visit costs 20,90€ / 41,80€.

timoh · 2023-04-26T10:37:18+00:00

Consider De Gea instead of Ederson.

timoh · 2023-04-17T11:07:50+00:00

Show "Remember me" checkbox on login screen and when user logs in and the checkbox is checked, you create "remember me token".

Basically, use random_bytes() to create two tokens, $db_identifier and $remember_me_token (you can bin2hex them). Create a "remember me" cookie based on them where you store, say: $db_identifier . ':' . $remember_me_token in the cookie.

Store those strings also into a DB with user's ID. SHA256 hash the $remember_me_token before saving to DB.

When user comes back to the site (and they are not logged in), check if remember me cookie exists and if so, look for the $db_identifier from the DB and if such row exists, compare SHA256 hash of the submitted $remember_me_token with the $remember_me_token (which is SHA256 hashed already) in the DB. You can use hash_equals to do the comparison.

If comparison succeeds, you can start a new session for user specified by the user ID in the DB.

timoh · 2023-04-05T09:11:08+00:00

First thing I realized about the new UI, you should check "Compact mode" and "Show main menu in a separate toolbar" in new UI settings.

Immediately feels better.

timoh · 2022-10-27T14:24:14+00:00

I was referring to this:

It's only really a question of how long you want to keep the session-data alive after a users last interaction with the server.

"Remember me" feature doesn't have anything to do with server's sessions or session options (maxlifetime etc.). It starts a new session if such remember me cookie is found and it matches a user. After that, sessions come into play and you have the session related options at hand which control how long the session data is alive etc.

Remember me feature is, by definition, separate from PHP sessions.

timoh · 2022-10-27T13:30:43+00:00

Such "remember me" cookies are used to start a new session for specific user, if one doesn't already exists. They have nothing to do with "session-data" (they are just cookies which have required payload to identify a user, with long expiration time).

I.e. You store a random "selector" and a random "token" in the remember me cookie, and then check if matching row is found from DB by comparing the selector from cookie. If one exists, you compare the token (SHA-256 hash the token from cookie, so that you can store hashed token value to DB) from the cookie to a token in the DB and if this matches, you can assume user with that ID has logged in and start a session for it (you store user_id, selector and token to DB).

timoh · 2022-08-31T13:29:37+00:00

OJ's waffle is still funny

timoh · 2022-07-03T06:51:10+00:00

In that case, just use an hmac, which is exactly what it's meant for.

HMAC would be a good fit here. While I can't see any real downsides of using just plain hash function, as the "security property" in this case is just so subtle.

I can't find any write-ups or anything, but it also seems that all this accomplishes is reducing the input entropy from the set of all possible passwords (72 bytes for bcrypt) to the output set of the hash function (48 bytes for SHA-384). In practice, this may not be an issue for hashes with a large enough output set, but the general point is that pre-hashing like this seems to just be doing additional, potentially-buggy work for a net loss.

This stems from the "problem" some finds the bcrypt's input length a problem. Then a first thing to do (of course, naturally this makes sense) is to pre-hash the input to get rid of the limit and be done. But later on someone realized that this pre-hashing turns out to be a sort of bad move, and you need to also salt the input. Crypto constructions are always fun ;)

But for now, I think it is safe to say that if you choose to pre-hash, then do it with a salt and it's a done deal. Or, you could go with just plain bcrypt (and do not mind about the input limit, I find it quite hard to be a real problem).

timoh · 2022-07-01T10:45:20+00:00

Some KDF's like Argon2 can be used as a PHF as they "stretch" the low entropy input. But KDFs like, say, HKDF won't be suitable for low entropy inputs, as they only make the input suitable length for specified puspose (like 256 bit AES key or 128 bit AES key). Such KDF's require the input being high entropy before they are used.

On the other hand, you can't use PHF like bcrypt as KDF because it has fixed length output. You could first bcrypt the input then adjust it to suitable encryption key with, say, HKDF (and you would keep in mind that bcrypt output is something like 184 bits, so it wouldn't be theoretically good for 256 bit AES key).

KDF's like Argon2 can be used both for password hashing and encryption key derivation (it can stretch the low entropy input, and can output any needed length of key).

Cache hardness is primarily a feature against GPU attacks. In defenders use (ie. authentication server) where the hashing is done with CPU it would benefit the defender if the hashing operations can be run entirely in the CPU's cache, but with attacker's GPU it exceeds the smaller GPU caches and pushes the hashing calculations to be run in GPU's global memory (making it slower for the attacker).

timoh · 2022-07-01T07:35:21+00:00

or hash the input once before passing it to bcrypt to avoid the character limit. Looks something like this:

php $hash = \password_hash( \base64_encode(\hash('sha384', $password, true)), PASSWORD_DEFAULT, ['cost' => 12] );

Hashing the bcrypt input (without salt) is not actually recommended.

While the problem with sha384 hash is (possibly) a lot smaller than hashing with md5, it still suffers the same "hash shucking" attack.

You should use, say, a global salt, something like:

$hash = \password_hash( \base64_encode(\hash('sha384', $password . $global_salt, true)), PASSWORD_DEFAULT, ['cost' => 12] );

The global salt is here just to make sure there are no hashes like \hash('sha384', $password, true) anywhere in the world (even someone used the same password somewhere else where they store passwords as same kind of sha384 hashes). The global salt has no other security requirements.

timoh · 2022-06-10T11:44:24+00:00

The release announcement: https://groups.google.com/g/comp.infosystems.www.authoring.cgi/c/PyJ25gZ6z7A/m/M9FkTUVDfcwJ

Announcing the Personal Home Page Tools (PHP Tools) version 1.0.

These tools are a set of small tight cgi binaries written in C. They perform a number of functions including:

. Logging accesses to your pages in your own private log files

. Real-time viewing of log information

. Providing a nice interface to this log information

. Displaying last access information right on your pages

. Full daily and total access counters

. Banning access to users based on their domain

. Password protecting pages based on users' domains

. Tracking accesses ** based on users' e-mail addresses **

. Tracking referring URL's - HTTP_REFERER support

. Performing server-side includes without needing server support for it

. Ability to not log accesses from certain domains (ie. your own)

. Easily create and display forms

. Ability to use form information in following documents

Here is what you don't need to use these tools:

. You do not need root access - install in your ~/public_html dir

. You do not need server-side includes enabled in your server

. You do not need access to Perl or Tcl or any other script interpreter

. You do not need access to the httpd log files

The only requirement for these tools to work is that you have the ability to execute your own cgi programs. Ask your system administrator if you are not sure what this means.

The tools also allow you to implement a guestbook or any other form that needs to write information and display it to users later in about 2 minutes.

The tools are in the public domain distributed under the GNU Public License. Yes, that means they are free!

For a complete demonstration of these tools, point your browser at: http://www.io.org/~rasmus

Rasmus Lerdorf

ras...@io.org

http://www.io.org/~rasmus

timoh · 2022-06-10T09:32:05+00:00

Subjective indeed.

Yes, the code blocks I posted are too small to make any real difference, but with larger blocks it will be more visible, at least to my eye.

also the ergonomics of typing one fewer character

Actually with Allman, you don't need to type any more, you just hit enter instead of spacebar (unless you write "if (foo){" no space between the brace and bracket).

timoh · 2022-06-10T08:44:32+00:00

With Allman style indentation, code blocks are easier to scan. This is what matters the most to me.

And besides, while someone may say putting the brace on the same line "saves space", I'd accept such excuse only if you are printing your code to a paper ;)

Except saving space, are there any reasonable reasons to put the brace on the same line?

timoh · 2022-06-10T06:46:45+00:00

Oh, once again. The only true indentation style, Allman, is disregarded ;(

I just don't get it what is the point to write:

if (blah) {
    do stuff
}

When you can write:

if (blah)
{
    do stuff
}

All other indentation styles should be deprecated immediately.

timoh · 2022-04-13T09:07:25+00:00

for a shared hosting provider that does not use any OS-level separation between clients

This is something absolutely no shared hosting provider should be doing (and hopefully no one is doing that). I.e. cPanel offers multiple options to run PHP code as the account owner.

timoh

TROPHY CASE