There is a need for people, especially system developers, to have a clearer understanding about secrets both for identification and authentication. This also relates to privacy since our secrets must remain private but we may also want to keep information private that is not related to security.
Information used for identification doesn’t necessarily need to be secret but if it is used for authentication it is important that it is secret. Also a secret that a user shares with many different people, systems, and/or services isn’t a secret. Many password implementations don’t take into account the limited capability people have for maintaining secrets or even recognizing what they should keep secret. Even if the information isn’t used as a password often public information is used for password resets which isn’t very secure. The following article raises these issues with the example of birth date which shouldn’t be used as the sole piece of information to identify a person and never for authentication.
A good security system should leverage a small set of secrets that users clearly understand should not be made public and are not directly reused. An example of indirect reuse is to have a master password that creates a unique password that is generated with encryption software from some context specific information like the address of the web site.
A few days ago I read a report about the dangers of making one’s date of birth public on the web. “After all, unscrupulous people can make use of that data and commit some sort of electronic theft.”
And I thought to myself, what utter tosh. That’s about as meaningful as saying “Most car accidents take place within three miles of home, so don’t drive near home”. Or even “most murders are committed by people known by the victim, so it’s best not to know anyone”.
Currently there’s a lot of personal data freely available on the web, particularly with the advent of electronic social networks. And currently it is possible to misuse that data in order to commit some crime or the other.
So something has to be done. Agreed. But. Rather than make people “hide” personal information, surely the answer lies in making better security “devices”. Surely the answer lies in making a person’s date of birth (or for that matter a person’s mother’s maiden name) less “valuable”.
I don’t know, I must be growing old. Sometimes I look at what we do, and I think to myself: First we take living things and make abject skeletons out of them. Then we carefully build cupboards around the newly formed skeletons. And then we wonder why we have skeletons in cupboards.
We shouldn’t have to hide simple information about ourselves. We shouldn’t have to worry about the Semantic Web, and how people are going to misuse personal information for the most heinous of crimes. We shouldn’t have to worry about “our past catching up with ourselves”. We should not build systems that make use of simple easily-accessible information as security tokens and devices.
Of course we should teach people to be prudent about what information they make available on the web. But let’s not forget that the web has always been about openness and transparency. That this is a good thing.
For centuries people have been putting spare keys under mats and in plant pots and over door ledges. For centuries unscrupulous people have found the spare keys and put them to nefarious use. The answer to that problem was not to change the locks, but the unsafe practice. The right unsafe practice. In this particular instance, the unsafe practice is the use of dates of birth and stuff like that as security tokens.