Is it a good idea to "combine" authentication methods?
Example we can use username/password method to authenticate a user from a server.
What if we used this as a first authentication step to get another token to use for subsequent authentication?
The token could be anything e.g. client's x509 certificate
Client sends password over SSL. Password is correct and server stores the client certificate send over SSL as trusted. From now on we have client authentication

  • There are two answers, with two different interpretations of your question. (I'm researching and drafting a third answer with a third interpretation.) You may wish to revise the question to clarify what you are proposing and what you perceive to be the core use case and potentially the core mis-use case.
    – MCW
    Commented Feb 15, 2013 at 17:29
  • @MarkC.Wallace:Updated with example.I don't know about misuse.That is why I ask
    – Jim
    Commented Feb 15, 2013 at 17:36

3 Answers 3


If entering a valid username+password pair grants access to a "token" which is used to authenticate with regards to another server, then you are mostly propagating the first authentication. It then really depends on the specifics of your setup.

For instance, suppose that you have a certificate-with-private-key file (as a PKCS#12 file, aka "PFX") available on a server. The server will send it to any user who successfully authenticate with a password. The user can then import the certificate into his own machine, and use it to connect to another server which requests a client certificate. For the overall system, you are using password-based authentication, because an attacker just has to guess the password to obtain the certificate, and then be granted access to the second server. However, the attacker could also try to hack into the first server, and will get the certificate, and then will be able to authenticate to the second server.

As the example above illustrate, this is a generic rule: when you link authentication methods as a chain of successive steps, you tend to obtain something which is as weak as the weakest of the links (for once, the "chain analogy" works well).

There are other ways to combine authentication methods, and are known as multi-factor authentication. This is what happens when a server requires several authentication: you may access the data if you type a valid password and you show a valid certificate. Contrary to the example above, the second authentication method is not unlocked by the first one; instead, the server requires both, independently of each other. In the "chain analogy", the authentication are not successive links in a single chain (the attacker just has to break one link), but nested reinforced tubes (the attacker must pierce them all).

  • My example is the inverse of yours.The user provides password and the server gets the user's certificate for subsequent client certificate authentication.Does your analysis still apply?
    – Jim
    Commented Feb 15, 2013 at 17:17

Sure. Requiring more authentication methods (also known as 2-factor authentication -- though typically the one of the factors is a randomly generated code sent to your email/phone) in principle makes you significantly more secure. You should consider that it is more of a hassle for users, which may trigger account reset mechanisms more often and may cause users to leave your service or be significantly annoyed. That is you may consider doing this if you are operating a bank, but not necessarily implement this if you are authenticating writing to a blog.

Managing X509 certificates is not a common task in the browser and these certificates often expire, are difficult/annoying to transfer between browsers/computers, so may lead to a bad user experience. For example, I dislike how startssl.com (which you can use to get free SSL certificates for websites) uses browser certificates to authenticate users -- often I've upgraded my distro in the past six months and didn't think to migrate my old certificates -- or even if I did the browser certificates typically expire on a similar timescale to the SSL certificates, so I have to create a new account anyways. I also dislike how my credit union forces me to create and click on a bookmark every time I login (use username/password + click on a bookmark unique to one computer which never works as I never find the right one or generate a new bookmark through token to the phone which I have to click on before I can login); in fact I've moved most of my money out of that credit union largely for the bookmark step in the login procedure.

EDIT: I interpreted your answer different than Thomas. I believe your system required after the account is setup, for you to have both a X509 certificate as well as type in your username and then password. If you meant you can login either way, (with only the certificate or with only the username/password), then Thomas is right you are as weak as the weakest link.

EDIT2: For your updated example, I see little to no security improvement over just using a random server-generated session token to manage sessions and having very long-lived sessions that use http-only secure cookies.

Can you explain what the benefit you are trying to accomplish? Is it merely user ease at future attempts of logging in?

How will your scheme handle users who change their X509 certificates. Let's say a user logs in from computer 1 with Certificate 1. Can the user later log in on from computer 2 with Certificate 2? Could an attacker who obtains U username and password, create a fake certificate and later login as U? Can anyone who has temporary access to a users browser trivially export their saved browser certificates? (Without going through the hassle of installing keyloggers, etc).

You only get strengthened security when you always require both factors. When compromise of either factor can bypass the other factor, you have weaker security.

  • Can anyone who has temporary access to a users browser trivially export their saved browser certificates? But isn't this an issue with client certificate authentication in general?
    – Jim
    Commented Feb 15, 2013 at 18:23

The other two answers are correct; as far as they go. I interepret your question in a larger context. From my perspective you seem to be discussing a variation of what most of the community calls "step up assurance", and NIST calls "Assurance Level Escalation" Section 6.1.5 in the referenced document. The fact that you're imposing the escalation early in the session isn't really relevant to the threat profile.

As @Thomas Pornin states, if all the UN/PW authentication does is disclose a token, then the question devolves down to simple implementation details. But if you're talking about assurance escalation, then the question becomes rather interesting. How do we assess the increase in security /reduction in risk resulting from two sequential authentications.

The trivial answer is to assume that the adversary will only exploit brute force, and add together the anticipated time to break. Realistically, we need to model the weakness of the UN/PW implementation, the implementation of whatever you're proposing as the second authentication (you say "anything, could be a certificate", but that doesn't tell us anything about the implementation).

Analyze to what extent the two reinforce or subvert one another. Are they truly independent, or do they rely on the same identity proofing or registration? Are the implementations truly independent, or do they create an artifact which would allow me to bypass one or both.

Finally, is the increased complexity from two authentication implementations worth the cost? the majority of security schemes fail not in theory, but because the implementation fails to correspond to the theory. (this is one of the primary reasons why we don't roll our own crypto.) Could we get the same increase in security by simply increasing the UN/PW length? Or making a corresponding enhancement in the certificate?

And have we gold plated a non-essential part. If you put a platinum plated authentication scheme in front of an encryption algorithim that is vulernable to BEAST or CRIME, or whatever, then all the effort you've spent on your superlative authentication is wasted.

To my mind the most likely sweet spot is registration and identity proofing. Simplistically, you're treating the UN/PW as a registration for the certificate authentication. If that is the case, then the question is academically interesting, but practically you're better off improving the resiliency of your certificate hierarchy.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .