Paid Advertising
web application security lab

Email as Half Factor Authentication

Over the last several years I’ve noticed a disturbing trend in web application security - the use of email as a form of authentication. Once upon a time web application security was a very obscure concept, and as such it made sense to rely on a simple (although largely inaccurate) assumption which is that users have complete control over their email address. Let’s think about this for a second. How are emails being used today?

According to MAAWG between 80-85% of all email is abusive. Okay, so the user is inundated with spam, viruses, trojans, phishing emails and other scams and that represents the vast majority of email they will receive. That means a pathetic 15-20% of email is actually “good” or non-abusive.

I don’t have any real data to back up how many email accounts worldwide have been compromised but I do have statistics on how many of the top two web mail servers have been compromised with some form of attack. Both Hotmail and Yahoo mail have had issues, but let’s not forget Gmail too. At one point I met with an AOL business person and they told me that the number of account takeovers they had were “in the percentage” range. He was unwilling to tell me how many percent, but even if it’s 1% of users that represents over 500,000 accounts.

Okay, so email is both insecure and highly targeted for malicious activities. Now let’s look at how companies are using it. Many companies still require that users use an email address as the primary username for their accounts for logging in. Companies reference the accounts as such. That makes it extremely easy to identify users, and potentially difficult to guess since there are billions of email addresses out there. However (and here’s the fatal flaw) the servers allow access to their websites by using email as a forgot password function.

So an attacker can get access to your email, (given the flaws in the webmail systems) they can look through the email, (since they have access to it) they can connect to the websites (which you have kept information on), they can use the forgot password function, (which generally asks for nothing more than an email address) and now they have access to your account.

Websites use email as a form of half-factor authentication. While it isn’t something you have, it is something you know that is not normally out of your control. In this way it is very easy to gain access to websites given access to an email account. People don’t generally think of their web mail as being a critical asset. That’s where they sign up for random websites since they don’t want to use their work account while shopping for lingerie. But by putting so much faith in the webmail application they now have risked whatever can be done on any website they they have an account with. A disturbing trend, to be sure.

11 Responses to “Email as Half Factor Authentication”

  1. maluc Says:

    ya.. more and more i realize what a gold mine someone’s email account can be

    find one XSS in google, yahoo and hotmail, and digg. then make a random site that forces people to dig it - and also steals their email cookies in the background.

    as long as your server can survive the load .. you’ll have more email accounts than you’ll know what to do with.


  2. RSnake Says:

    Very true… distributing the load with large scale attacks can be somewhat prohibitive, but I’m sure a determined attacker could figure something out. Squid isn’t too complex an application after all.

  3. maluc Says:

    Well if you outsource as much as you can.. images to photobucket, flash to youtube, external scripts/pages to free hosts that can handle it .. you can probably keep the load per person below 20kB or so

    i dunno how many actual simultaneous users that works out to on a 100mbit line.. but probably enough to keep someone busy with shopping

  4. Jungsonn Says:

    I never understanded that developers build a forget pw function into sites, forums, etc. This allready shows that there is something wrong with it’s security, if it is stored in a hash you can’t turn it around so it must be stored in plaintext somewhere. Ugluck…

  5. apnovi Says:

    Yeah there are definitely problems when you get an email back
    from a site with your password sent in plain text.
    I mean unless there using a reversible encryption method for passwords rather than just hashes, I wouldn’t know how many general sites would bother with that though. Also that would probably mean there is one administrator password hash stored in a DB or a file on the system which could be used decode everyones password. Scary but better than plain text!

  6. apnovi Says:

    I forgot to add…If someone was going to bother putting reversible encryption in there database for password storage so they could decode them to return as plain text to a user on an email erm..dont its a bad idea.

    As a rule you should never send a users password back….thats why verification questions are a good idea and of course store the users answers as hashes preferably with SHA 256 or 512 just like there password!

    If they forget both there password and their security question theres not much help for them anyway!

  7. maluc Says:

    well, security questions are pretty easy to guess.. particularly when you know the person whose account you’re trying to hijack. as for the reversible encryption, you really should never get you password back in plaintext, ever. Except for one possible method. But normally, i think the better method is to just send the person a new randomly generated password to login with, then have them change it to whatever.

    The one method which could return a plaintext password to your email without giving admins access to your plaintext pass is the following:
    It essentially a 1.5 factor auth..
    1) take the persons password, example: applesauce
    2) append a long string of random bytes after it
    3) hash the full string and store that as a checksum. also store the password length
    4) take the persons answer to their secret question, and use it as a privatekey to encrypt the password+randomstring
    5) do NOT store the secret questions answer anywhere. not even a hash.
    6) when someone forgets their password, ask them the secret question. Use that answer as the private key to decrypt the password+randomstring.
    7) hash the decrypted string as see if it matches the checksum.
    8) if it does, email the first bytes of the decrypted string equal to the password length

    This requires an attacker to both know the answer to the secret question, as well as gain access to their email account. Someone with access to the database has no way to determine the plaintext pass without bruteforcing the secret question’s answer. This requires a user to never forget their secret question’s answer, or their fucked - an admin can’t help even if they wanted to

  8. jungsonn Says:


    Indeed, reversable encryption (like almost all encryption) ’cause you to need a password to decrypt it:) it a bigger security risk, ’cause you only need 1 password to decrypt them all. That’s why hashes where invented. sha1 or sha2 doesn’t matter, what matters is that if done correctly you salt the hashes with a “unique.random.key” that key you store someplace else, done so, the rainbow tables become useless and bruteforce the last method. Best you can do these days.

  9. Legionnaire Says:

    For me “plaintext” is a forbidden word in a public network. Having something any password being e-mail back to you is too risky. Even in real life when banks e-mail your ATM card and then, a few days later, you ATM PIN it is very easy for someone to steal both of them. If he manages to get access to your physical mailbox, what’s stopping him from stealing both envelopes? Of course the two envelopes minimize the risk but don’t remove it.

    As mentioned above, a web site’s/company’s policy relies too much on the fact that you have control of your e-mail account. That’s rather stupid if you ask me.

    A security system is as weak as its weakest link.

    And in this case, that link is the human factor. They may have the most paranoid firewalls and ultra-secure protocols but relying on something you cannot know for sure (Who is in control of an outside e-mail account) just brings the whole thing down.

    It is my belief that let’s say 80% of Internet users follow this security hierarchy model: one e-mail account for the vast majority of their other online accounts (forums, web sites, e-commerce activities, etc).

    So it’s like an upside-down tree. If the root is compromised, all hell breaks lose.

    And if you take into account that a great deal of web sites does not ask for any kind of authentication when you need to reset/remember you password… They just mail it back to you or mail you a new one! In any case, the attacker will be able to log in.

    Aside from the scenario that someone has compromised your e-mail, the unverified “reset” password feature might cause a lot of frustration to someone you want to harass. You just reset their password twice a day :P

    Finally, since there’s a little bit of discussion here about reversible / irreversible encryption in password storing, I believe one-way (hash) functions will do the job.

    Since nowadays most online services rely on an one-factor authentication method, it is vital to protect it as much as we can. By that I mean minimizing the risks. A reversible algorithm relies on some form of key. Since that key is the responsibility of the owner (aka client) you can never be sure how strong that is. It may be his middle name or his birthday or his license plates. (again) It is not acceptable to invest time and money on a system that can be rendered ineffective by some man’s plain logic.

    To sum up, I’m not blaming the users. We’ve said many times here (and in other talks) that the security must always strengthen in the server-side. We shouldn’t make the user’s life difficult.

    P.S.: I don’t know if you know about this but there are a LOT of websites that in the name of better service ask for your e-mail username AND PASSWORD! For example a site asks for them to get your address book contacts and e-mail them a reminder on your birthday. That same site does not use an SSL session while you submit that information nor provides any guarantees on how they will treat it. And even if it did I would feel extremely uncomfortable in giving away my password to anyone. If you have the time, read about this here and don’t forget to check out the screenshot!

  10. maluc Says:

    Yeah, i’ve seen that on several sites lately, where they ask for your email password in order to spam people in your address book. The most recent of which was In their ‘invite’ menu if i remember correctly. (it was just yesterday, but i can’t even remember what i ate for breakfast ^^)

    And again, no SSL. But honestly, getting hacked via network sniffing or compromised hops is slim - compared to all the other ways of being attacked. It’s the security equivalent of dying by polar bear attack. So people should really calm down about the lack of SSL in sensitive areas. Sure it’s a bad hole, but it doesn’t scale very well, and there are many other more efficient ways for phishers and bad-hackers to obtain sensitive info.[/end rant]

    And you’re right.. for most purposes a hash of passwords is a simple and efficient way for password checking. But… developers really MUST add some kind of salt. just appending “eZ3#Þ” to every password then hashing, is a great solution. Users can’t be expected to choose difficult passwords. When they choose something simple like ‘albert’ or dictionary md5 crack of a stolen passhash cookie will make short work of that back to plaintext. The “eZ3#Þ” salt will completely thwart that.

    It’s no cure-all though, since if they pwn the site’s cpanel, and are observant enough.. they can easily extract out the salt along with the password database. I see unsalted hashes in my cookies far too often - especially from CMSes

  11. id Says:

    I think you underestimate the amount of sniffing that goes on, especially in corporate environments. I’ve had more than a few audits that turned up network/system admins that have installed password sniffers on proxies, IDS’s, etc…of course when confronted they always say they did it for “troubleshooting”. That may be true in some cases, or even all, but it doesn’t change the fact they have access to hundreds of users accounts at that point.

    When I ran security for a very large ISP with just corporate customers I had access to tens of thousands of user accounts had I chosen to. While access there was closely controlled to just a couple of people that were trustworthy (of course just my opinion), I don’t have faith that your average home user ISP, or small business ISP has done background checks on all of their employees, or enforces security to a high enough degree.

    As loose as security is at most ISPs, I wouldn’t be surprised if the majority have sniffers on them somewhere in their network.