Bcrypt Step-by-Step

Step 2) There is no step 2

Side note, I've seen a number of places (including the Scrypt repo) compare bcrypt brute-force benchmarks without specifying the bcrypt work factor.

It's very frustrating to see this, considering the time to compute a single bcrypt hash can be I'm not familiar with scrypt, but it looks like instead of providing a work factor, you can provide inputs like "max time to compute hash" and "max percent of ram to use computing hash" which presumably scales up as hardware becomes more powerful?

It's not generally productive to nitpick between secure password hashing/key derivation functions. Unless you specifically know you can't use one of these in particular, you should just pick whichever one has a safe implementation in a secure cryptographic library that you can use.

Basically, just don't use MD5, SHA1, SHA2, SHA3 (including Keccak and the other contenders) or some non-cryptographic hash function.

Back in the days before hashed or encrypted passwords, there was an interesting security hole in TOPS-10 on the PDP-10 due to direct password comparison.

Guess the password "aaaaaaaa", but put it in memory so that a page boundary falls between the first and second "a", and the second page is not resident.

TOP-10 allowed a user process to ask to handle its own page faults. Do that.

Now get the system to check the password. If your page fault handler gets called, you know that the password comparison got past the first "a" and tried to check the second "a". If you get a "wrong password" error, you know that the first "a" was wrong.

In the latter case, bump the first character and try again. You can discover the first character this way in at most N tries, where N is the number of characters in the character set used for passwords.

One you have the first character, repeat, this time with the page boundary between the second and third characters. Similar for the rest of the characters.

TOP-10 had lots of interesting security oversights. For example, the login system call, which was used by the login program to actually log you in once it verified your credentials, did not actually require any privileges. Its only restriction was that it only worked when executed by a process that was not logged in.

It turned out the login program was not the only program that could be run without logging in. You could also run the program to show the print queue. That program had a command to run other programs. Thus, you could walk up to any terminal that no one was logged in on, run the queue program telling it to run the debugger, and then from the debugger execute a login system call to login to any account you wanted. Oops.

TOP-10 also had some security things it did way better than Windows or Unix do today, such as access control lists. It used a totally different model than the "ACL as part of the file metadata for the file the ACL controls" model.

Instead, the way ACLs worked is that first the system checked the normal file permissions. If they allowed the access, it was allowed. If they denied the access, it then checked a flag that said the caller wanted to check ACLs. If that flag was not set, the access failed. If the flag was set, the kernel sent a message to a user-mode daemon, FILDAE, describing the desired access. FILDAE then got to decide if the access should be allowed or not.

The way FILDAE worked is that a user could have a file, ACCESS.USR, which FILDAE consulted. I don't remember if it looked for ACCESS.USR in the same directory as the file someone was trying to access, or the home directory of the file owner, or something else.

ACCESS.USR contained access rules, one per line. An access rule could specify a file or files (wildcards were allowed), a user (wildcards allowed), a group (wildcards allowed), an accessing program (wildcards allowed), type of access, and whether it was allowed or not.

So for example, if you wrote a game and wanted to maintain a high score file, you could put rules in ACCESS.USR that specified that anyone could write to that specific file if and only if they were running your game.

You could develop simple naming conventions that fit your security model, such as files whose name started with "pub" in a directory were publicly readable, and files whose names started with "prv" were not, and you could easily make exceptions for particular files or people or programs.

I think this fits in a lot better with the way most people naturally thing about access rules, making it a lot easier to avoid ACL mistakes.

I'd like to see a FILDAE for current systems. (Although to be fair, it does add some complexity that ACLs in metadata do not have. Because it was a separate daemon, there was the issue of communication between it and the kernel. People found some bugs that let them get FILDAE and the kernel confused about which FILDAE replies went with which requests).