Aug 9, 2011 12:49 PM
Help us get the strong authentication landscape and language right
-
Like (1)
It’s easy to come by classification of technologies for strongly authenticating users. But as my colleague Andras and I work on our upcoming Forrester TechRadar™ on strong auth (set up a Research Alert here), we’d really like to hear from you about the distinctions that truly matter for your business, the distinctions in the industry that you find to have no basis in reality – and the authentication methods that are too, shall we say, exotic to consider in practical terms. This is where the sci-fi movies Minority Report and Demolition Man often arise as cautionary tales…
In this report, our plan is to focus solely on technologies that 1) are at least stronger than a static password or PIN alone and 2) ask the user to perform some action, versus pure server-side approaches such as interaction risk scores generated through silent tracking of device IDs, IP addresses, and so on (risk-based authentication), after which you might choose to escalate to a more intrusive method. We feel there’s a nice bright line around risk-based authentication; it’s the subject of a forthcoming Forrester Wave™ (Research Alert).
So which strong auth technologies, according to the above definition, do you see as being relevant enough to make the cut for our deeper analysis? And what classifications make real practical sense for enterprises? Here’s a proposal for rough categories that capture the kinds of business decisions we’re seeing based on our client inquiries and observations to date. They're listed in "strength order." Do you think this breakdown makes sense? (Usability, breadth of applicability to business use cases, and relationship to identity assurance standards are other axes we’ll ultimately consider.)
And here’s how the individual authentication methods that we’re considering (in bold) stack up to the categories. Are we missing any that you think we should be paying attention to? Are any listed here striking you as bizarre?
We look forward to your feedback, and to hearing your experiences as we delve further into this work!
Eve, Where does Google's Risk Based Authentication w/ 2-Step verification fit in this picture? Saqib
Hi Saqib-- You're referring to this system, right? My take is that the texted one-time password method falls into the "out-of-band second factor" category (OTP delivered by SMS) and an on-device app that generates the OTP falls into the "in-band second factor" category (software OTP token). The latter is a bit less inherently secure than the former, but may very well be fine for the risk profile/use cases for which a Google user might use it. Have you used it yourself yet? From my understanding, they have major concerns about usability, and in an environment where the service remains optional, a lot of users have too little natural incentive to turn it on. However, I can see where it would be attractive for Google Apps customers and any relying parties that demand that "level of authentication".
I found an interesting recent post by Marty Schleiff that explains the implications of in-band vs. out of band. He draws some finer distinctions about vulnerabilities in things like Trusted Platform Modules, but his overall mantra is definitely a useful one: anything goodware can do, malware can do. (Hard not to have a tune going through my head when I read that, and add "...better"!) In discussions I've been having with clients lately, it seems like going to out-of-band methods is a leap that many are willing to make, with the smartcard vs. OTP delivered OOB choice being a matter of size and autonomy of population (and the biometric option still counting as relatively exotic).
Would love to hear your (and others') thoughts about all this.
Hey Eve,
Yup I do use google's 2-step verification extensively. It is a happy medium between usability and security. In 2-step verification, Google prompts the user for the 2nd factor only if it thinks the risk profile is higher than the normal for e.g. the user is logging in a from a new machine etc etc. One significant advantage that Google's 2-step verification has over blanket 2-factor authentication is that it removes the motivation for the user to leave the session open unnecessarily by making subsequent logins easier. What Google has tried to tackle is human nature, and not necessarily absolute security.
Unfortunately, as you mentioned, Google has left enrollment for 2-step verification as optional. There is no way to enforce that even on Google Apps for business, and there is no incentive for the user to enroll in that 2-step verificaiton program. This is one thing I don't like about google's 2-step verification offering. Hopefully Google will make the enrollment enforceable in the enterprise settings.
Saqib
Hi Eve, great topic. On the biometric front, these are usually additional factors and biometrics alone does really support 2F. Most often its combined with possession (e.g. a smart card, secure element, device (phone or computer).
Hi Sal-- Great to see you here. (I think you mean "does not support 2F"?)
This is a great point. The biometric authenticator itself is "a factor", typically delivered with or through "another factor" to make (at least) two. So, e.g., voiceprint authentication (a thing-you-are) needs to come through a pre-registered thing-you-have, like a phone connection associated with a particular phone number. Some of the items listed in the 2FA bucket are obviously bundled into two factors, like an OTP delivered over a thing-you-have. But several of the items leave this implicit (something I struggled with in trying to make the original post not too horribly long).
Is it worth making this fully explicit in all cases, that is, naming the factors used? Or would simply qualifying the description of the various sub-buckets as, say, "biometric-based" or something like that be equally helpful? Or is the issue bigger than this?
Yes, does not, glad to know you are reading this, should send more your way :-)
When adding factors binding matters. As you point out, the phone, or the smart card as the something you have is bound to the something your are and the strength of the binding affects the strength of the factor, if this is done in person with "enrollment officer" it provides the most strength. So we need to be carefull as a self-asserted something you are doesn't really do much, you just get the bob@gmail problem morphed.
I think you go to the explicit to understand the real strength and its (factor_strength) (binding_strength) (factor_strength) where the proudct is what matters These then can be bucketed but best bucketed or graphed as product and not factor.
Hi again Sal-- It certainly makes sense to consider the nature of the binding of the factors. Is it a fair baseline to make pre-binding in a different session or by some other channel (if not precisely at enrollment time), using at least the strength of the subsequent authentication that is sought, definitionally part of any of the technologies worth looking at? E.g., in the case of delivering OTPs to a mobile phone, the user would have to have registered that number earlier in "equally trusted" fashion prior to needing it for this transaction.
Yes, Eve, exactly. The extent factors are out of band or session is important and necessary. In some ways this is like an admin looking the other way when you type in the password (always wondered about this). As you know factors have strength based on keys (e.g. length of password/OTP, number of bits in RSA or AES, number and uniqueness of points in biometric template). The proper binding allows the strength to be maintained and then used to multiply the strength of another factor, again typically the something you have. Also I always find myself going back to this Bruce Schneier article from 1999 where he talks about hard to forge and easy to steal. So I guess you also have an implicit factor in creating the strength factor which is difficulty to steal which is related to the method of creating and the method of binding we are talking about here. http://www.schneier.com/essay-019.html No wonder its called a chain of trust (yes slightly different from authentication but related), the overall strength is "linked" to the factors and the steps taken to create and bind.
Hello Eve,
a great topic to cover. Just one addition to the authN technologies to at least consider reviewing. The Generic Bootstrapping Architecture still holds the promise as strong authentication factor with the help of UICCs. I could not give you a state of deployment in live networks here, but as the number of mobile data network users grows, this technology might gain traction and relevance (also with the handset vendors).
Regards,
Peter
Hello Peter-- Interesting indeed, thanks for sharing this idea. Can you comment on vendors who are at least considering incorporating it?
Well, as first pointers I would list Ericsson (they started a labs project for GBA) and NSN but there might be more. Forgive me, but I am no analyst ![]()
Regards,
Peter
Thanks for all the additional insights; keep those cards and letters coming. By the way, I've started getting some feedback on Twitter as well; if you want to be sure to catch my attention there (I'm @xmlgrrl), just use the hashtag #ForrAuth for this subject.
(A comment made there so far: What about authentication offerings that are "in the middle", e.g. services? Agreed that they're definitely part of the strong auth landscape! We do have to cast our net a little less wide for the purposes of applying our TechRadar methodology, unfortunately. But at least the risk-based authentication angle will be covered in a separate Wave.)
Eve,
Thanks as well, ISO 24745/2011 also goes to a lot of this. http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=52946
Your point about risk based techniques also makes a lot of sense. We have been working with an old friend Emmanuel Mazer and his company Probayes to apply a version of this based on Bayesian inference, some of the major credit card clearing houses in France have leveraged their technology and approach http://www.probayes.com/index.php/en/solutions/bank-finance . I try to stay clear of company references but this is pretty cool stuff and as I said Emmanuel is an old friend, hope its OK.
Best,
Sal
Here's another challenge for y'all. I didn't list fingerprint authentication initially. Are people interested enough for it to be covered?
I think that will be a good idea, Eve.
If you are going to talk about Fingerprint authentication, you should cover some mention of privacy aspects. For example, there are certain birth defects that can show up in a fingerprint.
Jumping beyond the methods, there are more secure ways of handling fingerprints and less secure ways that are important for people to understand. So a deeper dive in terms of published research would be beneficial.
Excellent point. In fact, many authenticators -- most especially, but not only, biometric ones -- can be revealing of PII by their very nature. We'll try to provide perspective on privacy implications of authentication. (I actually get a little suspicious of cloud services whose end-users aren't truly customers (but are, rather, the product) when they offer to collect more user data for the ostensible purpose of stronger auth, but also likely for selling/mining that data. )
Hi Eve
are you interested to hear of a new method to authenticate whereby a fourth authentication factor is introduced in addition to the known 3 factors?
It is all about adding location awareness to the object that needs to be authenticated.
The story is rather long and includes in-space technologies; The method has been studied for a number of years now and has been validated by academics as well as ESA the European equivalent of the US NASA.
I am the father (or mother if you like) of the technology that uses GNSS Global Satellite Navigation Systems such as GPS in conjunction with terrestrial systems.
It may sound complicated but works without complicating existing systems while using to the extent possible COTS technologies such as cell phones.
Like to hear more?
Robert
Seems like Garmin's been doing this for a bit with their GPS units for a bit. If you add a pin to your GPS, the only way to unlock it if you forget the PIN is to be in your "security" location - which could be your home (but shouldn't be).
Additionally, location awareness really just increases the "risk-factors" doesn't it? If I see you trying to auth from Stockholm, and your cell phone location returns that your last known location was in Philadelphia (because your cellphone doesn't have connection in Stockholm because your company didn't spring for a world phone)... Then what?
However, it certainly could work much like Garmin's stuff I suppose - you could set a number of "standard" locations...
So, while Eve may not want more on it, I wouldn't mind. I'll PM you my e-mail.
No this is not at all Garmin like stuff. Garmin knows about tracking not about authentivcated localisation.
Adding a PIN to a location is - sorry to say - a non issue.
I like to add a bit more. GNSS signals are broadcasts emitted by the satellites and contain certain information. Receivers pick up these signals and compute a position, velocity and time (PVT) if sufficient satellites are in view.
Garmin and TomTom and the likes takes this to determine a position.
Here is the innovation.
Do not compute the signals but use them to arrive at a number of things.
1) Randomness and entropy based on the orbital drifts (Keplers laws do not apply for various reasons)
2) Ditto due to jitter of the atomic clocks on board of the satellites.
This is used for cryptologic applications btw. and the reason why the Euroean Space Agnecy was involved (as well as certain persons from the defense industry).
Now the above has also been "adapted" to fit into commercial applications.
If you are interested I can dweel a bit further on this.
Robert
PS: Re. your question we have field tested this in diffrent parts of the world, and no it does work with standard locations
Is there any harm if the Pentagon turns the skew back on for GPS?
Or are you using Galileo? GLONASS? Combination of the 3 (somehow)? And what form-factor are we talking? You seem to indicate that it plugs into what we have access to today (like cellphone?) but I'm not aware of many current devices that can decode all three...
All very interesting, Robert.
In fact Andrew I like to use the generic name for SATNAVS which is GNSS. Indeed I can do this with GPS and the future Galileo. GLONASS is still a bit different as certain specs remain undisclosed.
Current receivers in cell phones are GPS enabled and we see that bit bu bit dual GNSS chips become avialable. In the near future such receiver chip will be cheap enough to have multi GNSS Ie. with all possible SATNAV constellations including Asian operators.
What is very interestiong is that we can also use multi frequencies instead of the single frequency receivers a cell phone currently has.
All this makes that location aware authentication becomes absolutely secure and solutions are already available to mitigate spoofing, replay, meackoning and other attacks.
To add some further spice, in addition to authenticating the object/person we also authenticate the location from where user authentication is requested in addition to authenticating the transactuion that is requested by the user (which can be simple access to a guarded area but can also be to personal assets such as bank accounts, personal files stored at a remote server etc).
It is very exciting I agree.
Robert
Hi guys-- Thanks for the interesting contributions. This location-based approach sounds like it's being deployed in a fashion that's nonintrusive from the user's perspective, which puts it out of scope for the current exploration but would likely be touched on in our Risk-Based Authentication Wave. If I understand correctly, Robert, there also seems to be a hint of "location-based encryption" (??) in what you're describing.
(By the way, to tie this to the privacy sub-thread above, there's a "Location Privacy" group on LinkedIn that I follow. You may be interested as well.)
Eve
GNSS systems are not surveillance system that can spot you and then track you. In fact they are mere in-space orbiting beacon system that have simple single channel bradcasting means.
You indicated that this method is out-of-scope while it doenot "ask the user to do some action". The above implies that action needs to be undertaken and that is what the user in our system needs to do.
One of the reasons why the user needs to be involved is to be compliant with privacy legislation that is applicable here. While the user wants to provide location related data at the one hand s/he does not want that this is done on a permanent basis.
Again this is not like a camera system that looks at the surface of the earth to identify people.
Robert
I hope that you will take this discussion into some new territory.
For example, not all forms of out-of-bound authentication are created equal. Consider SMS and dial-back. The security of SMS is based on the security of the carrier's network and the security of their user's accounts, both of which are very questionable. In fact, carriers are disincented to increase the security of their user's acounts. The cost for password resets would sky rocket. A dial-back system from an authentication provider would have it's incentives aligned. However, the vendor is still in the middle and should be part of the risk landscape. This may be fine for most companies, but many were surprised to find RSA in the middle of their authentication systems.
I would also like to see the issues with biometrics addressed. Secrets are only useful for authentication if they can be changed. Biometrics can't be changed. If my fingerprint is compromised (and it is because it is everywhere) and you use a fingerprint system, how will you accomodate me? Once a database with my iris scan is compromised, how will you accomadate those users? Biometrics may have their place, but I find it hard to see where they could not be replaced by something simpler and less expensive.
HTH,
Nick
Could this be negated by something like RIM's PIN messaging? It's different than the carrier SMS stuff... Of course that would require RIM to support an e-mail to PIN gateway of some sort...
Nick,
I have done some work on authentication including using biometric data. One of the problems with this is that there is no randomness in the biometric token (ie; after your fingerprint or retinal scan has been digitised); Of course one could encrypt the result with a randomised key but the end result is that you need to maak something dynamic from something static.
This is important while else the digitised result can be stolen and your identity is stolen with the fingerprint.
To a certain degree the biometric token is the weakest of the three known factors but has ben considered safe in the past while people's perception was that something unique remains unique totally forgetting that it is easy to forge.
The difficulty was in properly obtaining the raw biometric data, something which is still the case (to a certain degree) for the human DNA but is not anymore when fingerprints are concerned.
Robert
One quick comment on your point about the variability of OOB methods: Yes, absolutely. I'm actually finding a couple of different aspects of this variability:
not sure i follow the 2nd point. They have to be logging in on some 'band' right? If the PC is 'owned', then the attackers will just own the session not matter what authentication method is used.
Autheitcation will not stop malware. Anti-malware tools are supposed to do that. DLP is probably a better bet.
True that the session could just be hijacked after it's established. I need to learn more about the Duo method described below, which may be describing the type of "closed-loop" solution I was thinking of, where the authenticator is confirmed entirely in the secondary channel (like answering a phone call and pressing the right buttons, or equivalently responding to a text with another text). What are the scenarios (if any) that make the new OOB OTP methods truly attractive on security grounds?
I had a quick read on this Duo Push.
To me it seam to be a way of encrypting the comms channel. While authentication plays a role in setting up the session it seems to me "yet another mousetrap" or a slight variation on a well known theme.
The method requires to associate a request with a representation known to you however in the form of a picture. There is no real difference in recognising a picture compared to a digital represntation of a character or digit. In other words when you are required to select 4 digits out of 10 and provide them in the proper sequence (which is basically a PIN) then this is definitely more difficult to solve than selecting one out of 10 (or 6).
I agree it is more convenient!
Robert: to your point about PINs vs. images, you’re right that having a user enter a PIN is also a type of “shared secret.” However the key difference is that a PIN is static and is therefore susceptible to keylogging malware. So, for example, if the business requires the user to entera PIN in order to access the soft token or in order to open the SMS message containing the OTP, that PIN can be captured using keyloggers planted on the phone and will no longer provide protection. In contrast, the image-based approach proposed by Confident Technologies is dynamic and changes every time.The pictures are different every time, in a different location on the grid every time, and the pieces of authentication code associated with each picture are randomly paired, to form a unique OTP each time. By being dynamic and creating an OTP each time, it is not susceptible to keyloggers the way a static PIN is.
Unfortunately, the sad truth is that many two-factor authentication solutions don’t even require a PIN from the user. My bank (and many other businesses) simply sends a text message to my phone with an authentication code clearly displayed in the text. I use an iPhone, which displays the text message OTP right on the phone’s screen – visible for anyone to see -- even though my phone is password protected.
I am not sure whether a PIN is by definition is static and an image isnot. I PIN can be as dynymic as you want , unfortunately PINs were usually implemented as a static credential. I like to cite the TAN (Transaction Authentication Number) as a typical example of a dynamic PIN.
Dynamic PIN do avoid to a certain degree the keylogging problem.
A point I should like to make with images is that 2064K is right arguaing that this method will be commercially speaking a dead-end street.
However the method of confirmation of the authentication process using PIN/TAN/SMS or even images are flawed anyway and a paradigm shift towards a totally new and secure authentication method is needed.
Eve: The "closed loop" you refer to is exactly what we designed for - a trusted path (in classic Orange Book terms) to the user to authenticate at the granularity of individual transactions. It is not just another OOB OTP delivery mechanism, nor does it only "encrypt the comms channel" as Robert asserts. It provides message-level security to authenticate entire transactions over a secondary channel to the user independent of the compromised PC. We start with the assumption that the user's computer is compromised, as it often is. And yes, we do stop malware like Zeus. We'll post a demo video soon. :-)
When we originally released OpenSSH (see the ssh manpage - half of us were in Ann Arbor :-), people said the same thing - it's just another encrypted transport (like Kerberized Telnet, SSLTelnet, STel, etc.), which completely missed the point. The underlying trust model (for server keys, trust on first use (TOFU); for users, pubkey auth without PKI) is what actually made it usable, and led to its success as a de facto standard.
Robert: You've confused the two screenshots posted here, without regard to who posted them! Duo has nothing to do with these image-based methods, which have been attempted time and again as well (unsuccessfully - e.g. Vidoop). I don't know why these ideas, long since abandoned in the academic research community that studies usable security, are still attempted in industry.
must have had put up my old glasses! I agree with you sorry for the mix up.
Hi-- I'd like to dig into this more with you; had been meaning to study up on Duo generally anyway. I'll reach out, or if you get there first, feel free to shoot me a note at emaler@forrester.com.
(BTW, I'm on record as being a fan of TOFU for at least some purposes...)
I have now taken more time to read more into the matter.
My first comment would be how quick they are able to process the second channel transaction, an important parameter for payment processors;
The idea of using a graphical or image-based approach to authentication has definitely not been abandoned in the academic research community. Numerous academic studies on the topic have been published within the last few years(2009 – 2011) in IEEE, the Association for Computing Machinery (ACM), the International Journal of Computer Science and Information Security, just toname a few. Recent research and proposed approaches have been published by Microsoft, Carnegie Mellon, and many different academic groups at universities within the last couple years… precisely because a visual approach to authentication has been shown to so usable. I’d say the academic research community are actually the ones keeping these idea alive as a viable approach, and it’s the industry that has not yet caught on. ![]()
A lot of the academic literature reviews the defects of graphical authentication, such as the security indicators users commonly ignore, or worse, provide a false sense of security (e.g. http://www.kottke.org/07/04/sitekey-sucks).
IMO, it's not that our industry has yet to catch on. It's the market that's spoken (although I'm "Confident" you'll figure out what to do with the remains of Vidoop at your employer ;-).
My 5-year old might have fun playing "bingo" or "memory" on the computer, but for most folks requiring this at login is just goofy and annoying. And doesn't actually improve the security posture of organizations dealing with endpoint compromise.
FWIW, I'll be talking about the security and usability failures and future of two-factor auth at next month's United Security Summit in San Francisco. Hope to see you there!
You’re referring to SiteKey, which is an anti-phishing tool designed to let the user know that they are on the legitimate website and not a phishing site. It’s not a tool for the business to authenticate the user.
Graphical approaches to user authentication have been demonstrated in many academic research reports to highly usable and secure…whether or not it can be successfully commercialized is the question that remains to be seen.
Sarah, here you suddenly mention "graphical approaches" contrary to the "image" methods you referred to before. In my view the firts concept is much wider than the second.
I tried to find where the other picture comes from and here it is.
These guys use "multifactor authentication" out-of-band.
I refrain from comments but ............ what should I say
Re: If the PC is "owned"
If a perpetuator had been able to steal the authentication tokens before then no matter what you do as the legitimate owner of the terminal you are out-of-luck. This goes far beyond than owning a session.
Re: Authentication doesnot stop malware
Assuming a clean state whereby the legitimate owner has full control and its credentials have not been breached then authentication will stop malware. Malware needs to penetrate first before it can start messing things up by acquiring levels of authorisation.
Eve --
You make a really astute observation and an important conceptual point about “band-ness” as a continuum. The “band” used to access the online account and the “band” that is the mobile phone are not truly independent. Rather, they are interconnected at the user level and attacks like Zeus/Zitmoare able to “spread” from one band to the other – demonstrating your point.
I’d also be interested to hear if you’ll address in this report the question of how to provide strong, multifactor authentication when the user is browsing the web or accessing the online account from their smartphone. As we all know, people are increasingly using their smartphones as their primary device for accessing the web, so many of the multifactor authentication approaches used today that rely on the phone as the second factor will no longer provide adequate security.
(Whew, trying to catch up on the various sub-threads. Great input, everyone, thanks a million.)
Yes, the problem of strong authentication into mobile apps is something that definitely interests us. You're right that the "band-ness" in this case doesn't look good for strong auth, as the mobile device is precisely the primary channel you want to use in performing some access-controlled task.
This also makes me think of the more general question of what fallbacks are available in the cases where highly device-specific methods fail or aren't available (e.g., keystroke dynamics vs. keyboardless devices).
Just to keep you on your toes, here's some more complexity :-).
We use asymmetric encyption in our tokens. This allows us to send other information throught that channed. For instance, on our PC tokens, we can validate an SSL certificate for the user. We do this by sending a hash of the targeted site's SSL cert along with the OTP to the token. Before the OTP is presented, the token goes to the URL via the user's internet connection, grabs the cert, hashes it and compares it to the one from the WiKID server. If they match, the OTP is presented and the browser is launched to the URL. This prevents a network-based MiTM attack. For admins, this means that if they can focus on their DLP and anti-malware needs without worrying about a user connecting to an evil WiFi connection. You can find more here: http://www.wikidsystems.com/learn-more/technology/mutual_authentication.
I think this points to a need for a risk management approach rather than just a "landscape and language" approach.
Nick
This is all 20-year old stuff (tokens, callback, SMS). Which we've implemented out of necessity for our customers, but doesn't move the needle in terms of security.
Where does a system like our host-proof Duo Push smartphone-based authentication fit in? Intuit calls us "context-aware authentication". Bruce Schneier calls it "transaction authentication". Our users call it "two-factor that doesn't suck" - high praise in this industry segment!
Bottom line - no two-factor auth system that completely fails when the user's endpoint is infected with malware (a safe assumption, as we've seen time and again) can be called "strong".
Under the category of out-of-band, dynamic secret 2FA, I would like to propose the following type of image-based approach be included:
As a second layer of authentication, it requires the user to apply a shared secret on the second factor device itself (the user must identify which pictures match their secret categories by tapping the appropriate pictures on the smartphone display). Therefore, it is a multi-layered, multifactor solution (requiring something the user knows on something the user has). As the user identifies the correct pictures on the mobile device, the mobile application communicates directly back to the business’ servers, thus it remains completely out-of-band from the web session.
Because the user must have knowledge of their secret categories, it is more secure than sending an authentication code in plain text as an SMS message (which someone else could read and use to fraudulently authenticationif they stole your phone or if they use a Zeus-in-the-mobile attack to intercept authentication text messages). Even if someone else has possession of your phone (through loss or theft) or if they were using Zeus malware to intercept communication and steal data, they would not be able to complete the authentication because they would see the image grid but they would not know which images to select. The images are different every time and generate a one-time authentication code (OTP) but the user only has to remember their few secret categories and look for the pictures that match their categories.
Here's an example on an iPhone:
As a side note, are you considering covering how one would provide strong, multifactor authentication to a user who is browsing to the website from their mobile phone? In this scenario, common two-factor solutions (such as sending an OTP to the phone by SMS) would no longer be considered an out-of-band, two-factor approach. As people increasingly use their smartphones as their primary devices for browsing the web, websites will need to have a mutilayered, multifactor solution to provide strong security.
I would question the claim that multiple static shared secrets (e.g., security questions) are in any meaningful way "enhanced."
A. Multiple static secrets are cryptographically equivalent to a single, longer static secret.
B. "Security" questions based on demographic information that is not easily changed by an individual and is static over their lifetime (mother's maiden name, city of birth, etc.) assume that the user trusts the security of the system requesting the additional information. While I may well trust my bank with my money or a made-up passphrase for the moment, do I trust a third-party processing company with information that I can never retract once disclosed? If the answer is no, then my only option is to invent answers to these intrusive personal questions, and then attempt to remember what I answered for any given servicer. This is at best not an enhancement to security from the user's perspective, and at worst a huge security hole for the individual.
C. The lack of certainty from a user perspective about just what shared secrets are required for access at any given time also opens the door for a man in the middle attack to phish for large amounts of private secret data. How many times have you tried to log into a bank and been told you first need to answer multiple additional security questions. In my experience, I am asked to share additional secrets far more frequently than I am asked for already shared secrets. While this is partly an implementation issue, it is representative of the type of pitfalls inherent in this approach.
I would argue that a single static shared secret (e.g., pass phrase) is superior to multiple shared static secrets when the user has no control over the number of shared secrets, their content, or future usage. Your Category 2 should be less satisfactory than your Category 1.
Forrester Research, Inc. is an independent research company that provides pragmatic and forward-thinking advice to global leaders in business and technology.
Forrester supports leaders in 19 roles across three distinct groups: IT, Marketing & Strategy, and Technology Industry.
Aligned to your professional role, Forrester's analysts are experts in the specific technologies, issues, and trends currently impacting your business.
Fresh thinking and collaborative problem-solving through an unmatched combination of peer networking, forward-looking analysis, and professional guidance.
Our expert analysts apply custom research-based solutions and data-rich insight to your critical challenges and opportunities.