I've had an interview question we called KennyLoggings.
Pair program on a feature that lets you change the log levels of your rails app based on the path and class hierarchically. So you could set INFO for app/models but DEBUG for just app/models/user.rb.
I quite liked it as an interview question / and as a tool.
It's funny, but slightly disappointing that it uses special characters, camelcase etc. -- in my mind there are two kinds of passwords/phrases:
- Those that you are NOT expected to memorize because they go into a manager, and can therefore be N character random strings with characters every possible variation (max entropy)
- Those that you ARE expected to memorize because they should be kept out of a manager, and in order for them to be N characters they need to be memorable, like lowercase-only phrases/sentences connected by hyphens or similar (max memorability)
This example of a "strong" password from the webapp is neither:
Sometimes I have to type passwords into apps or websites that my password manager does not work, or on other devices like my TV or game consoles. There's a middle ground between your options that's perfect for these scenarios.
My password manager can generate passwords like
> DWOW!psap.rair2vim
It's split into 3-4 character groups, with numbers and symbols used to delimit each group. It's memorizable without (intentionally) using words, and fairly easy to type with a remote or controller.
I think we agree that passwords should be adapted for their use case, but my point is also that in a lot of cases it's not motivated to use a password that "looks random" if you're going to have to type it in yourself.
"DWOW!psap.rair2vim" has ~118 Bits of entropy, but that's still less than this string (~129 bits):
> ggggg-eeeee-aaaaa-rrrrr
Remembering "the word gear, separated by hyphens in groups of 5" is trivial, and it's not a bad password. A lot of people think that it's a bad password because it "looks" insecure, but it's not: it's only insecure if the attacker has previous knowledge of the structure of the password, which they won't.
Of course it's not unthinkable that dictionary words with up to 10 repetitions separated by hyphens would be a part of some kind of generated dictionary list, but you can always "pad" the password, or do whatever else to make the structure that you came up with less predictable while still being memorable (to you), like:
> !ggggg-eeeee-aaaaa-rrrrr! (~147 bits)
> ggggg-eeeee!aaaaa-rrrrr (~135 bits)
You mention one of the things that is commonly understood as a "bad thing", which is "using words": that's not by itself a bad thing unless your password is the word, as soon as your password changes to "gear!" the dictionary needs to be expanded, the same goes for "gear!!!". Both of these are not good passwords, but my point here is that the fact that a word is included in some shape or form is not in itself a problem: if you have a password that's over 1,000 characters long composed of nothing but the word "gear" being repeated, that doesn't make it an easy password to crack with no prior knowledge.
Strictly speaking it depends on your threat scenario but it is true for the very common case where an adversary gains hold of a database dump of passwords that have been hashed with a fast hash function.
First of all humans are not nearly as creative as they think they are. In the end it's always the equivalent of the key under the doormat, in the plant or under the stone next-by. Maybe windowsill, but that's it.
Secondly everyone can run an unbelievable amount of password candidates on consumer hardware at home. There are huge candidate files with all the passwords ever leaked and every word on Wikipedia and every song text and every book title and so on. For a fast hash you can run all of this in a couple of hours on usual hardware.
Thirdly, because of the way GPUs work you get variations like appending a number or leetspeak for free. The reason is that the limiting factor for fast hashes is the memory bandwidth between CPU and GPU. Essentially the GPU is bored while waiting for candidates so it can as well try some variations in the meantime.
Troy Hunt also wrote about this topic from a bit different angle: "The only secure password is the one you can’t remember"
This reminds me of the time I got banned from a karaoke bar for singing Danger Zone too often. They said I exceeded the maximum number of Loggins attempts.
Ain't that the truth. I once was locked out of my work systems for a day or two while IT investigated, turns out a trailing space at the end was...not disallowed explicitly, but would result in a broken account everywhere but your laptop.
I had one weird login where the limitations were done on the input field (but not enforced on the backend), so if I typed my password in, it didn't work, but if it autofilled with a password manager, it did work.
I had the opposite happen to me. The password length was enforced on the frontend by JavaScript, which the password manager bypassed. The backend recieved the whole string though, so I could only log in by pasting in the password, which got truncated by the client side JavaScript. Drove me nuts until I figured it out.
I don't hate it. I need a keepass version though, especially reskinned with the Ken Log theme they have here. Maybe add a sound byte when generating a password.
The amount of ideas that Karl had which came to reality, that Steve and Ricky dismissed as mental is what keeps me listening to Youtube compilations of their show to this very day :D
A logstash-esque service called "Kenny's Loggin'".
A plugin for a password manager to autotype credentials called "Kenny Logs In".
An OAuth service called "Kenny (or she) Login?".