Empty Security & Vitamin Cookies

In my previous post, I mentioned the “wicked son,” the vendors who want to give their customers a sense of security, but do not actually want to implement any cumbersome security algorithms. I had a customer using H.323 who sent me specifications for a security implementation for H.323 where the password wasn’t known in advance, and asked us to support it. When I mentioned to them that they were showing the password in the open, where anyone who wants can simply catch the “Setup” message and read it, they answered that no, they were not, they were sending the hashed password to the other side. That was even worse, as they were saving eavesdroppers the bother of finding out which hash was being used, and they could immediately use the sent buffer to decrypt the media.

Users are usually of the “simple son” type, they want a sense of privacy. They want to feel that their web mail, their online files and their VoIP conversations are protected from casual observation. Usually, they do not expect someone to plant bugs in their home or deliberately crack their email password, so a closed door with a “do not disturb” sign should be enough. They want to be asked for a user name and password, and once they are, they feel secure. The fact that the password was passed free for all to see, and that the media may or may not have been encrypted is of little concern to them - this is all technical stuff, let the technical people deal with it. Stranger still, most of the time this works. If something is locked, or appears to be locked, people will hesitate before tampering with it. Not using security at all is like talking in public - anyone around can listen in, but it’s not all that polite. Using some sort of basic security is like talking quietly somewhere away from the crowd - anyone who really wants to can listen in, but it’s embarrassing for him to intrude. Using real security is like speaking in a room behind closed doors with concrete walls with acoustic isolation; safe, but hardly anyone will take the trouble. I may ask, “What’s the harm in that? RFC 2617 explains:

The Basic authentication scheme is not a secure method of user authentication, nor does it in any way protect the entity, which is transmitted in cleartext across the physical network used as the carrier. […] It SHOULD NOT be used (without enhancements) to protect sensitive or valuable information. […] The danger arises because naive users frequently reuse a single password to avoid the task of maintaining multiple passwords. […] In the server’s password database, many of the passwords may also be users’ passwords for other sites. […] Basic Authentication is also vulnerable to spoofing by counterfeit servers. If a user can be led to believe that he is connecting to a host containing information protected by Basic authentication when, in fact, he is connecting to a hostile server or gateway, then the attacker can request a password, store it for later use, and feign an error.

So not only do the basic forms of authentication lull the users into a false sense of security, they are dangerous to their real security.

Recently I was asked to add the basic authentication to our RTSP stack, which supports the digest authentication. After refusing, the customers added basic authentication by themselves. I couldn’t help but be reminded of the book “What to Eat”. In the book, Marion Nestle resents vitamin enriched cereals and candy - the claims as to the health benefits of the additives, she writes, are there just to make us forget the (high) caloric value of the product. When a video terminal asks us for a user name and password, we are led to assume that there is some form of security involved, just as the announcement to vitamins and iron added to breakfast cereals makes us believe that the manufacturer has some consideration to our health.

We should be more aware about what we eat, so should we also be more aware of how we protect ourselves.