Three Ways Usernames Put You At Risk

WWPass
4 min readJul 25, 2017

--

by Brian Kelley

Usernames aren’t doing us any favors. They only serve one real purpose: locate the data that’s ours so we can apply a password to it. Since there aren’t any reasonable or more convenient alternatives to recalling data, this process isn’t about to change anytime soon. For now, a “username” is the most intuitive data label, and that’s bad.

The problem with usernames in public or private networks is that they serve another purpose: They make it easier to find you. It makes sense when you WANT to be found by a trusted source or an audience. The problem is, it’s hard to filter out the wanted attention from the unwanted.

An important distinction between a data label and your name could save you or your customers a lot of trouble.This should be the where the username ends, and an online “handle” begins. You need an intuitively named email address or social media name, so people know which person to search for and contact.

By no means should that handle be the same as the label that’s on all of your encrypted data. Because almost everyone uses them this way, there are three main dangers that usernames pose, and why it’s important to change how we use them.

1) Usernames function as an address

Usernames point straight to the record of the user because it’s needed to verify that user. There are numerous ways hackers can abuse this: Methods such as SQL injection can recall usernames and the data they link too, even if they can’t get past the password part. If hackers steal the entire database of encrypted and hashed usernames, then it provides them with plenty of valuable information.

It’s by far the biggest problem with usernames. The intruder gets an identifiable label that’s not easily changed, usually shared across multiple accounts, and easy to find elsewhere with the same hacking methods.

Passwords in comparison are easy enough to change in response to a breach like this. But an exposed username that’s the same across your accounts and may have financial info attached? A common and typically unchangeable identifier like this is a dangerous liability.

2) It’s part of your factors of authentication, and it makes the others weak.

It’s easy to overlook, but usernames exposure endangers your passwords and any other multi-factor authentication in place. Let’s say you do follow the standard password protocol and use something strong. It’s still no guarantee that it won’t expose the data in a network intrusion. And normally, the breach would stop there, and only one of your password-protected accounts is exposed.

When a username becomes the target, then more direct hacks will inevitably flood the user’s account. It makes it even worse when a username and the email address is the same. Because of this security oversight, the likelihood of spoofing and phishing just gets worse.

You can say goodbye to the effectiveness of security questions too, not that they were doing much good anyway. Recovery of an account has always been an essential requirement: People lose and forget things all the time. And like every other means of backup entry, security questions can be exploited when they know the person whose account their invading.

The consequence of passwords being simple to crack is inconvenient and near-constant resets, but at least it can block an attack for a short time. The consequence of usernames being on an active list of hackable targets, however, is just bad news for everyone. And the liability usually falls on whoever is storing the data.

3) They permanently expose your identity as well as the data

If usernames don’t get exploited outright, it’s still profitable on the dark web. A list of valid usernames are cheap to purchase on the black market because that’s one less step into an account. Knowing what to enter in the form field is the puzzle, and usernames give hackers a huge piece.

Also, how many usernames are the user’s full name followed by the year of their birth? Such a little benefit for user convenience can offer major details to the wrong person. And of course, for the sake of convenience, the same username is commonly used across multiple accounts. It’s terrifyingly simple: A social media account or email is a few steps removed from data that’s much more valuable to hackers and damaging to the user.

Are they even necessary?

Ultimately, real names or email addresses for usernames are never necessary. There’s no reason why the index of your data should ever need your name as a label, other than that’s just how everyone’s been doing it for the last 50+ years.

Personally identifying usernames hurt when services or apps connect to your financial or healthcare information. Banks and hospitals that employ usernames for their customers are really just letting security lapse and exposing themselves to constant intrusion.

The immediate solution is that usernames should be randomized character strings. In fact, it makes perfect sense to have a username that’s as random and complex as the password should be. They should also be unique to every individual account and service, so only one account would fall instead of a chain reaction.

However, even that’s not enough for something that should have extra security, such as banks, hospitals, or any number of large or small businesses with customer data. Alternate login methods such as security tokens are perfect for protecting financial or medical data, but that’s a tall logistic order for our mobile-centric lives and businesses.

Access control (usernames and passwords) ultimately needs to change. Every replacement, however, faces the challenge of being understood and accepted by users while also fixing the security gaps that have existed for far too long. But sticking with the current system while hacking methods advance could essentially mean an end to privacy. Protecting your username-labeled account with a password is rapidly becoming a futile effort.

--

--

WWPass
WWPass

Written by WWPass

Experts in multi-factor authentication and client-side encryption. Keeping businesses safe since 2008.

No responses yet