Disrupting the paradigm

Not sure if I am quoting here, but be careful when someone says they are disrupting the paradigm, often when you look beneath the vale you will find an issue. The paradigm is usually there for a reason, cause it works.

I have discussed factorisation of authentication before here, this one will be a little more indepth;


To reiterate authentication currently works under a model of factors. Factors are simply classifications of things, in a cumulative manner. Things could be something you know (and preferably keep private), something you have, something you are, somewhere you are. This is 4 factors.

Something you know; Pin, password, passcode, passphrase, pictures in a certain order, last 4 digits of a credit card (even though this is something you have, it is a known never changing string).

Something you have; a key, a key-card, usb fob, Certificate, smart-card, rfid chip, SMS/Phone call receiving phone, Bluetooth paired phone or other device, laptop, tablet, phone itself.

Something you are; fingerprint, iris scan, voiceprint, DNA sequence.
I will rant on biometrics later, but you can't re-issue a fingerprint so if it gets compromised and copied by someone you are out of luck.

Somewhere you are; GPS location, IP-gelocation (thou as this would be in band checked on the connection you may be using to access the service the security doesn't increase), a landline or mobile phone could also be somewhere you are, eg you login to an app and it calls you on a separate phone at that same location to ensure you meant to.

Lets look at some examples.

• You login to your computer with a username and password, this is 1 factor of authentication, just a password.
• You login to your computer with a username and password, then onto a super-secret corporate system with a different username and password, this is still 1 factor of authentication. You only used a username and password.
• You login to your PC using a swipe card only, this is still 1 factor of authentication.Yes you used something you have, but it was not cumulative on something you know.
• You login to your PC using your username, password and Secure USB key, this is now 2 factors of authentication, something you know and something you have.
• You login to your PC using your username, password, thumbprint and Secure USB key, this is now 3 factors of authentication; something you know, something you have and something you are.
• You login to your netbanking via their app with username, password, fob token code, and your thumbprint on the home button. The app has rights to your phones GPS, it disallows transfers over $1000 from anywhere but inside your own home or registered place of work, if you go to transfer $1001 to another account and it then allows you due to the registered GPS, this could be considered 4 factors of authentication; something you know, have, are, and somewhere you are, all checked to ensure valid authorization.

Now comes the paradigm shifting. I wish it was me that thought of these.

Device profiling
This makes the device a factor, specifically a second factor.
This will do things like take the IP you are logging in from weighted with things like browser headers and put them in a database, if sees these to dramatically change it can deny you access.
A good example shoring the power of this hidden data that you send can be seen at the EFF's Panotoclick here; https://panopticlick.eff.org/
There are certain banking and social media apps that do this already, alerting you via email when you have logged in from a new device.


Risk based authentication
Awesome idea, basically the application has some smarts. Similar to the above device profiling it does some device profiling and then if you fail it, it either challenges you for more authentication or simply denies you access. It has risk scores that it assigns to things, so risk +1 if you are logging in at a different time, risk +9000 if you are logging in from a country with a bad reputation that you have never logged in from before. This still works in the factorising model, but doesn't force a user to enter every-factor every time, it is an extension of the paradigm.

Pingrid and their ilk
As I mentioned last time, these aren't two factor. They are a challenge, with a user response based on something they know. Interestingly I think they do increase security, but still not as much as a second factor. This really doesn't fit the factorised model. See there demo here; https://www.winfrasoftbank.com/MyAccounts/Default.aspx
You can see how due to the randomness of the numbers it does reduce the likelihood that the users "password" will ever be compromised by an over the shoulder or man in the middle attack, but again repeat enough views of the users login through a screen scraper and you have them. Still doesn't stop Man in the browser attacks (where malicious code waits for you to authenticate to your bank then distracts you and gives control of that tab to the remote bad guys to transfer out your cash).

That being said, I think they are probably making the authentication process more complicated than it needs to be and not more secure. Hard tokens that are transparent to the user like Ubi-key or smart cards are much, much more secure.

So uhh disrupting the paradigm, I thought I could make case that the above three did disrupt the paradigm, but they don't. I started this article all gung-ho to prove to myself they did, but they simply extend what we already have.
Device profiling and risk based authentication either work with existing factors of authentication, or make a sting of numbers unique to you and your device part of auth (just like a certificate or token, and thus are a second factor), and pingrid is simply an extension of single factor authentication.

Seeing as I mentioned Schneier last time I posted about auth, I had a look to see is he has discussed pingrid or others, he hasn't. But I did find the below, which is awesome;
http://www.schneierfacts.com/fact/vote/631

Password Hints

OK let me preface this by saying this: I absolutely hate password hints and secret questions. Generally speaking anything you put in there can be found by friending someone on facebook, a quick google or simply guessing. They are the epitome of a bad idea, sure they have some use. If you forget your password the hint if constructed correctly could remind you and only you, however most people don't understand this.
If it is a secret question an answer, where the question is predefined such as mothers maiden name, it can take a few guesses (smith anyone), or a quick google.com search and you will have it. Everything else is trivial, and this was how Sarah Palin's yahoo email account was humorously compromised back in 2008.

Forgetting all that, adobe gave us another insight as to why it is bad.

I know a lot has been said about adobe, including the excellent (although conservative number of users impacted) article by Brian Krebs here.

But there is something else that needs to be learnt from this breach.
Sure your password hint could be terrible but maybe the web application logs someones IP when they go to that for later alerting etc if a bad guy does compromise the account. But what if the DB gets walked, and all those juicy password hints or secret questions and answers are stored in plain text... then you have a problem even if you correctly store you passwords (which adobe didn't).

So lets say you do correctly store your password as a per-user salted sha1+ hash, good, but now you allow users to have a password hint like adobe. When someone has their password hint as their password in another language then they fail very quickly. For example (this is not a real entry, but made to look like one from the adobe breach);

78114563-|--|-notreal@fakedomain.com-|-BsscHGd8aIjiwxG2CaWrHSw==-|-Gato x3|--

If we forgive the obviously non-hashed password in the 4th column, we see in the last column the password hint is simply Gato x3, or you know maybe Cat typed out three times. So even if this entry had an irreversible hashed password, the hint would give it all away if the DB where accessed.
Maybe they should instead store their hint as a reversible encrypted string with an individual key for each user. This would mean the server when the user wants to use their password hint would look up the key from the internally accessible internal key server for the username and decrypt the hint. It would mean if the db is walked via an SQL injection or direct attack they aren't necessarily going to get the keys to decrypt the password hint. For a secret question and answer, you should salt and hash the answer and if you are using user defined questions you should encrypt those too just to reduce what is leaked...

Using an encrypted password with the same decryption key for all users or using an unsalted hash means that the resulting password string whether it is BsscHGd8aIjiwxG2CaWrHSw== or 5e884898da28047151d0e56f8dc6292773603d0d6aabbdd62a11ef721d1542d8 will be the same across all users meaning if you break one you break them all. The same goes for your "password hint" or "secret question and answer", should people take my advice and start encrypting them.

Of course all of this only works if you care about security. If you aren't going to hash your passwords. Or worse store them in plain text as Cupid Media did, then you probably don't care about users password hints, and will probably store them in plain text.
Realistically no-one has any excuse now, google authenticator for two factor has been open sourced, OpenID, SAML can be used to authenticate you to a central store and then you are done, like UbuntuForums did, post their breach, move to UbuntuOne the openID provider. People like adobe should really switch to one of these, to reduce their authentication load. The users should be forced at these central providers to 2-factor auth. If you forget your password at one of these central providers then you have a convoluted way to retrieve it via out of band identification, via either partnership with a bank or other multi-vendor approach, eg go into these news agencies and show 100 points of ID to get your password reset.

My point I am trying to make is this, if it is used for authentication it should be encrypted, preferably and sufficiently strong hash (SHA1 or greater) that is salted. Nothing but the username and row ID of your authentication table should be plain text. It is only a matter of time before these passwords in the 10gb adobe database are broken and the key used to decrypt them is found, if it hasn't happened already.

Add these ~130million adobe accounts with the 42million from the Cupid Media and I think we should declare this month, change password November, I know the few sites that used the same password as my account on adobe have now all been changed, have yours? If you use the same password everywhere, then now is the time to look at keepass or lastpass to store your single use passwords in a manner that allows for your protection. Heck even Google's Chrome and Firefox have built in password managers with cloud sync and encryption, so there really is no excuse.

I am doing a CTF for some peeps, thought I'd put this here to be searchable.. these are the real sums of these phrases;
2D579CD75056723657B8FA68FA6626C245CD362030159965EFBDF41DA2D67ADF:redherring
86DB5B1C2D9C1854FE5B80318FBC806C53EDD2C5DBABAFA42CC909A867AE3E21:RedHerring
BC1A7086C334A3C3E2AC638DF4C82A58DEBC6CF2DAF05C4B1D17E9896BC69908:red herring
Or check it here; https://passwordsgenerator.net/sha256-hash-generator/ or on your bash shell with echo -n redherring | sha256sum

"1.5 factor authentication"?

A colleague recently tried to convince me that "1.5 factor authentication" was better than 1 factor so I decided to look into it.

First some basics, generally speaking Authentication works at its most basic level on computer systems via a username and password. This is 1-factor authentication. It is something that is unprotected and possibly public your username and something that should be kept hidden and secret your password or passphrase.
The 2nd factor of authentication in 2 factor authentication is the combination of something you have, some kind of encrypted token (usb key, rfid token, smart card, numeric-alpha numeric token; ala RSA SecureID and Wikid soft tokens).
The 3rd factor of authentication is something new, but it requires the first two in addition to another something you are. Eg; thumbprint, voice print, etc. Basically the 3rd factor is the addition of biometrics. I am really not a fan of biometrics as the only method of authentication as you can reissue a security token but you can't reissue your thumb. I can see having it in addition though would be workable.

See here for a more in-depth PCI view of these three widely accepted Authentication factors; http://pciguru.wordpress.com/2010/05/01/one-two-and-three-factor-authentication/

There is also a not yet well supported but interesting idea for a 4th factor. So in addition to all the other factors the computer or website or what-have-you authenticates that you are where you say you are. This 4th factor is hard to implement at the moment, and they are obviously trying to make it transparent to the end user, so say you have an app on your phone that fires up GPS and sends it through to ensure you are logging in from areas you have pre-defined. I actually heard of someone using log correlation years ago to this effect, basically they watched logins from the internal network and VPN concentrators and if a user attempted to VPN in from a geographically remote IP when they had only recently been seen more geographically locally or even on network then they would shut down the geographically remote session. I can't find the article now, but this supposed shut down a hacker trying to get into this USA based company using an Execs credentials via the VPN from South America when the exec had been seen on the local network only minutes earlier.
See here for more on 4th factor; http://blog.dustintrammell.com/2008/11/21/four-factor-authentication/

Now to get to 1.5 factor auth. I couldn't find much ;
Market-speak; http://blog.mailchimp.com/introducing-alterego-1-5-factor-authentication-for-web-apps/
Comment decrying it for being touted as 2 factor auth; http://stackoverflow.com/questions/559639/what-is-two-factor-authentication
Market-speak, but interesting implementation; http://pingrid.org/
Very aptly named blog; http://www.ryanhicks.net/blog/2008/10/15-factor-authentication.html
But onto this colleagues definition: 1.5 factor auth is a password and a pin... So still two things that you know. Yes it maybe prettied up in the case of pingrid or horrible and easy to break as in the case of the below screenshot from a banking institution here in Australia that I used to use, but still two somethings that you know, by definition still one factor, aka one of the definitions of factors above.

Onto the example I mentioned earlier, I used to use a financial institution that I believe started using the below (this is a mock-up I no longer have an account there) "extra factor" in 2003, I laughed when I first saw it, realising it added no real security. The idea is that you pick three images and you have to click them in order, the images get shuffled each login.
As I watched after more logins I noticed that the pictures changed, every time, except the pictures I as a user had to click, so if a user had my username and password they could simply login several times see the picture auth, note down the pictures then exit, do this a large enough number of times and like a game of "guess who" you have narrowed down the pictures needed to authenticate in this step. As there are only three and you need to click them in order you have to only make 6 failed attempts and you will have it.

The problem with this 1.5 factor is depending on the implementation it could be almost 50% more security that 1 factor but in the case of the above image that is probably 1.0000000000000001 factor. The other issue is even if it is 50% better than 1 factor it is not 50% worse than 2 factor, 2 factor is insanely better than 1 factor, coming back to implementation of course but even the worst is orders of magnitude better. Have a look at how complex pingrid is, I doubt that most end users would pick this up quickly and I would say 90% will write down what they have to do and what they do, do to get authenticated, this makes it no longer something that is kept secret, and may make authentication for legitimate users so hard that they fail more often, causing increased support calls and decreased productivity.

This half factor addition is bad market speak at best, and a false sense of security with a move to introducing vulnerabilities in the authentication chain at worst.

UPDATE: Being the security geek I am, I decided to email the venerable Bruce Schneier and his word from on high matches my own, "It doesn't (add security). It's a marketing ploy." Squeee I got a reply for Bruce Schneier... but yeah 1.5 factor is bs, coffin closed and put to bed.