Two Factor Authentication System_问答_开发者_运维开发者技术经验分享

I'm trying to design a two factor authentication system (on PHP) using SMS as the second auth method. This is for a test project thus can anyone help me to design this service?

This will be an web based system and below is what i have done so far.

Once the client enters the Username and Password the website will send a secure HTTP request to our server with the MSISDN, a UID (to i开发者_Python百科dentify the session), their UserID & PassWord.
Our server will add the request to a MySQL DB and respond the website with a Code, UID and some other info.
Our server will send the client a SMS with the one time password.
Once the client enters the OTP into the website, the website will send another HTTPS request with the encrypted OTP to our server and we will send a success or fail code as the response.

this is the flow i have thought about. Anyone have a better flow? or suggestions?

Thanks.

This may work fine, however it is not two factor authentication.

In addition to a password, a second factor can be:

Something you have (e.g. secureid, smartcard, etc).
Something you are (i.e. various forms of biometrics).

Since I assume you're not aiming for biometrics ;), let me clarify why I say this is not a 2nd factor (something you have).

In order to qualify as the 2nd factor, you would need to guarantee that the holder of the device (i.e. the pre-registered cellphone) is the only one who could possibly have received the SMS.
In todays cellular networks, that just aint so. There are hacks to copy e.g. a SIM card; the cellular operators can intercept; smartphones can have apps that intercept and resend; etc.
Furthermore, having the user type the code back into the website allows all the standard web attacks on that additional password: sniffing, interception, MITM, session hijacking, etc...

Now, to be clear, this still definitely has value - out of band communication can help ensure that the apparent user is not being victimized by a simple web attack, XSS, etc.
I've worked with a lot of telecoms that love this solution (it also happens to be part of their business model, but whatever ;) )

However, depending on your situation, some places (e.g. banks, gov't) require a real 2nd factor - i.e. cryptographic proof (usually). And this aint it.

Seems like a valid mechanism. But what if the SMS device is not in a service area? Or dead battery?

I would only add that sending OTP via SMS is still considered two-factor authentication. The comment from Avid is clear

2nd factor, you would need to guarantee that the holder of the device (i.e. the pre-registered cellphone) is the only one who could possibly have received the SMS.

But, the same would apply, say, for a hardware token based 2FA. How can one guarantee the hardware token is used by only one person? Stealing a dongle (or looking up the OTP on its screen) is even easier than intercepting SMS

@megazoid, have you considered using "2FA as a service" providers? Such as Authy.com , Token2.com or DuoSecurity?

Everybody still likes SMS but in my opinion it sucks. No matter how much SMS Passcode tries to improve the workflow.

An attacker could request an SMS and intercept the SMS without the user noticing it. For this he does not even need to steal the phone. And in my opinion this is the worst attack, since the victim will not realize, that he has been compromized.

When stealing a dongle, the user knows, that he has been compromized and the relevant counter measures can be performed.

Stealing the seed of the dongle from the vendor, is a much better attack vector, which was also shown in the past ;-)

This is why you should think of using hardware tokens, that you can seed yourself. So you can be sure, that the seed only belongs to you. Seedable tokens are the yubikey, eToken Pass and eToken NG OTP.

Anyway, for a "low security" environment even using SMS might be ok. But you need to be aware of the consequences. By the way, all those kind of tokens are supported by the open source project privacyIDEA.

I invite you to look for ideas in the clients we've open-sourced at Duo for our two-factor authentication system:

https://github.com/duosecurity/duo_web

Another place to look is existing 3rd-party authentication protocols such as OAuth and OpenID.

Two things you haven't mentioned:

The signed response should include a user ID, for comparison with the local user (probably stored in a secure session) to avoid replays
The signed response should include an expiration, or return a nonce given in the signed request

Ricky from Twilio here.

We just released a non-trivial, production-ready example Two-Factor Authentication tutorial that you can check out if you're looking for some inspiration for how to architect a system like this.