"Medical people love doing this"

Tangential to the actual issue, but in that field it's to prevent patient mixups, not to defend against malicious attackers.

I once saw a report about two persons having the same name, same birthday, and same birthplace. It really fucks up a lot of administrative databases.

I loathe security questions too, but those aren't even that bad! My credit union's default security question is "What was your first musical instrument?" I wonder how many guesses you get?? I always answer these questions with a long string of random characters.

LOL, check their Facebook pictures and see if they are playing an instrument in any of them. Most people don't play more than 1 instrument, so it's probably their first.

How many common "first instruments" are there for kids? Maybe 5? There's a pretty good chance you'll get it right without doing any research whatsoever.

It's not quite as bad as asking "what species was your first pet?" but not much better.

This is the real problem with security questions; the answer space is often so very small, and can be narrowed down even further with a little research.

Questions like "what was the first name of (your maternal grandmother, your first best friend, etc.)" are very common -- well, there are stats on most popular first names of given generations in different places. If you know what country the person is in, you can make a good guess at these.

It's not even that tough. Just guess "piano" and you'll be right 40% of the time. If you get a second guess try "violin".

I'm not saying I disagree, but how would you verify identity over the phone?

By allowing people to set their own questions and answers instead of a) using a pre-defined list of questions b) forming questions from information about the customer that friends/acquaintances usually know or information that can be found via a Google search.

You can still have the question. But my answer is a random 32 character string of alphanumerics :)

I algorithmically generate the answers to the security questions with:

     answer = PBKDF2(hmacsha1, password + question, "", 100000, 16)

This is also incidentally the basis for how I generate unique passwords for every service except banks, communication, and other sensitive things. I want a different password on every website and don't want to trust any password-remembering software I didn't write. The same function works fine for generating answers to secret questions.

This is morally equivalent to using a password manager to encrypt your passwords with a "master password". :)

Not really. I don't oppose using a master password, which I don't use anywhere directly or store on disk anywhere. I just don't want to trust closed-source code to manage passwords, and want to be able to generate the password to anything from anywhere without having to carry around an encrypted table of stored passwords. In this case, I implement it myself, with the help of some common open-source Python libraries.

Have a look at pass [1], it's a minimalist tool in bash that is so simple you can easily make adjustments to it yourself. The codebase is very small so it is easy to audit. The principle is that your password are encrypted with your public key. You can then use git to keep running copies of your encrypted passwords on many devices.

[1] - https://www.passwordstore.org/

Thanks! This is interesting.

I did say "morally equivalent" rather than "technologically equivalent".

By that, I mean the overall security of your password scheme is analogous to what people get out of a password manager.

Password managers are more secure. Here you just need the master password, with password managers you need the master password and the database file.

Still, a lot better than password re-use.

> I just don't want to trust closed-source code to manage passwords

KeePass? It's great, and open source.