The belief that we are safe from our enemies by protecting ourselves with usernames and passwords is founded upon two false articles of faith:
The fastest way to steal a user's data is to get at it like a user - this is like believing the thief will always use the front door because that's the way we get into our store so we leave our front door locked but our windows open. On second thought, with the poor security of most user's passwords, it's more like tying our doors shut with twine and leaving the windows open.
That theft is our enemy's goal. In truth, an enemy may inflict as much inconvenience or damage by locking us out of our own store while customers are waiting to get in, vandalizing our store, burning down our store or diverting all of our customers somewhere else.
Usernames and passwords operate at what network engineers call "layer seven" in the network, i.e., the application layer. Anyone can send any kind of data packet to the server. For example, the server may be a web server but user can try to send it Instant Messaging packets. The server will listen to all the packets and when a packet comes along that requests a service on that server which is password protected, the application running on the server challenges for the password. If the user supplies the correct password, they are let in and if they do not, the application waits until the next attempt. In the meantime, the server is still receiving all kinds of other packets.
Those other packets are a big problem. The server is getting all of them because there is nothing in between the users sending the packets and the server - nothing to stop those packets from getting to the server in the first place. Maybe those packets are for a service that the server is supposed to listen to like administration packets. Those are only supposed to be sent by a legitimate administrator and the server is supposed to respond to them. What if someone who is not a legitimate administrator starts sending them. Well the server will listen to them. If the enemy is able to compromise the server through those administration packets, they have a clear path to steal any data they want without ever needing to know the CEO's password.
Maybe those packets are for a service that the server is not supposed to be listening to but some lazy or overworked administrator forgot to tell the server not to listen to them. Since those packets can still arrive, they can still do damage. Perhaps the administrator forgot to turn off the built in web server on the file server and, because the administrator doesn't realize it is running, they never apply the latest security patches. Our enemy can send web server packets to that server, use a common exploit, i.e., a well-known way to breach security using the web server packets, and through this previously forgotten web server, grab the CFO's files.
These are examples of coming in through the windows rather than the front door. But remember that theft is not all our enemy may have in mind. Recall that there is nothing to stop anyone from sending any kind of data packet to this server. What if they send so many of just the right type of packet to this server that it is overwhelmed and can't respond to legitimate data requests? What if they keep sending just the right packet to make the server crash several times a day? What if they do this in a way that damages the data? - Maybe they haven't stolen it but they've kept you from getting to your own data.
What if our enemy's reason for attacking this server has nothing to do with the data that is on this server? What if they are using it to stage an attack on another server?- Maybe one of our customers' servers - wouldn't that be a good way to hurt our reputation? What if they planted something on this server to intercept traffic that gives them the usernames and passwords for another server. What if they plant something on this server to start sending out reams of unsolicited e-mail to people all around the world which then provokes those millions of people to send nasty e-mails back. This not only embarrasses us publicly but brings our own e-mail system to a screeching halt.
The root problem is that we are allowing any kind of packets to be sent to the server but we're only stopping the ones that are trying to come in the front door. The root solution is to stop unwanted packets before they ever get to our store. If we do that, they can't come in the windows, they can't lock us out and they can't burn down the store. This is called implementing security at layer three, i.e, we control which packets can make it to the server in the first place.
If you are a user, you are only allowed to send user packets that will require a username and password to the server. You cannot send administrator packets even though the server is listening for them. We stop those packets from everyone except the administrator before they ever get to the server. And remember that web server that no one realized was running until some hacker exploited it? Well, no one is allowed to send web packets to the server. We stop them before they ever get to the window so even if we forgot to shut down that rogue service, we are still safe(r).
The same with all those other malicious packets that had nothing to do with theft but everything to do with hurting us. We stop them from ever arriving at the server to do their damage by filtering them out at layer three. We place equipment between offices and even inside offices to separate our sensitive resources from danger. Why should someone who has tricked their way into our three person office in NoOneEverGoesThereVille as the telephone repair man be able to send any kind of data packet to servers housing our most sensitive data in New York, London or Hong Kong? If you are comfortable with that possibility, then by all means rely upon usernames and passwords. Otherwise, implement layer three security and stop those packets from ever hitting your servers.
So why should we not just rely upon usernames and passwords? Because the assumptions that we have made to assure ourselves that they protect us are false.
This short paper is a massive simplification of a very complex topic. It by no means fully explains or even mentions all of the issues. However, by just touching the surface in highly simplistic terms, I hope it opens your eyes to just how vulnerable most of our data is.