I am doing a HIPAA application soon and it requires 2 factor authentication. Can anyone give me an example? I am thinking a secure login and then a form that requires the user to enter their birth date or something.
Thanks,
Darren
There are 3 general types of factors:
“Something you know” – memorized information (e.g., a password or answer to a
secret question).
“Something you have” – possession of a unique item containing secret
information (e.g., a smart card, bar code, or USB-interface device).
“Something you are” – a physical trait that can be converted to digital
information using specialized hardware (e.g., a retina or fingerprint scan or voice
recording analysis).
You need to pick from 2 of these 3 categories to have true 2-factor authentication.
Wikipedia has a great listing of various types of Two Factor Auth. Check it out here.
2-factor authentication usually requires something the user knows, like a password, and a token from something the user has, like a SecurID fob, or nowadays maybe a biometric identifier, like a fingerprint reader.
A password & birthday, while being two distinct things, are both knows items and wouldn't constitute a proper 2-factor identification.
See this article or search for information using "2 factor authentication", Google and Bing both show lots of references.
What you're describing (password + verification input) is still single factor authentication.
Two factor authentication also requires something the user has in their possession (smart card, dongle, etc.)
Three factor authentication (for completeness) is all of the above plus some sort of biometric input from the user (fingerprint, retinal scan, hand geometry)
2FA will be simple One time password as hardware or software (mobile , PC ) and
we have done few deployments of 2FA tokens for HIPAA compliance.
CryptoPhoto is a very easy to use "Strong Authentication" 2FA solution, with additional protection aginst Phising and other threats. You don't have to ship expensive hardware gadgetry to end users either - it's a fully self-contained solution.
Related
I've become somewhat familiar with the concept and management of two factor authentication. Many suggestions for using it point to using a third party tool such as Google Authenticator.
However, what are some of the security concerns with a simpler 'home brew' approach, such as:
first requiring a username/password, then once that's authenticated to open a second form requiring a specific piece of information sent to the person's email (and/or providing a QR code scheme, and/or SMS message)?
It might sound like a silly question, because passwords of course need to be hashed and never store the original.
However, for API secrets, generally I see them displayed in the clear when signing up for them.
For example, if I go to the google api console and look at my credentials page, I can view my client secret, same for twitter.
Surely api keys are just as sensitive as passwords?
Is it just because from the provider side, you can be confident that a sufficiently strong password is being generated?
If that's the case, then that doesn't provide any protection is your database is compromised.
Or is it perhaps because if you are using token based authentication, you're either doing password grant type, which requires you to send your credentials along with the client id and secret, or a refresh token, so a user would have already had to have been compromised?
I can imagine a few possible answers to this:
In some cases, it may be required for the server to have persistent storage of the plaintext API key in order to satisfy usability requirements (Google and Twitter being examples).
In some cases, the API key alone is not enough to do much at all -- additionally one needs to have an authenticated account -- and therefore the API key by itself is of limited value (hence less value than a password).
In a number of cases, the API key is hardcoded in a client application (especially mobile applications, which almost always do this) and therefore it does not make sense to add the extra protection on the server side when the same token can be trivially extracted from the client.
The security industry is just not that mature yet. Maybe once hackers start dumping API keys, ideas like this may be taken more seriously.
BTW, I am very serious about the last point. The truth is that a lot of good ideas don't become a reality until there is a critical mass of support behind them. As an example, I once blogged about a related topic -- protecting user confidential information by hashing it in the database but in a way that it could be recovered when the legitimate user logs in. I used Ashley Madison as an example -- in that case, the hackers were more after email addresses, phone numbers, and physical addresses than passwords. So when the hackers snatched the database, they immediately had what they wanted, and they could care less about the bcrypt encoded passwords (in fact, some older passwords were encoded with only MD5!) Unfortunately, concepts like this do not have enough of a push to make them a reality. Even zero-knowledge web designs are very few in the real world.
Difference Between Two-Factor and Two-Step Authentication? How it is different from each other with an example?
In two-factor authentication the user will be required to provide information of two different types in order to identity themselves. Generally the types of information that will be required are a subset of the following:
Knowledge: Something the user knows (e.g. a password)
Possession: Something the user has (e.g. a physical key)
Inheritance: Something the user is (e.g. a fingerprint or retina scan)
With two-step authentication, there's more than one thing the user will have to do, but it may be within the same type of information. For example, the user will provide a password and a pin. Both fall within the same type of information, something the user knows, but it still is a two-step procedure.
There's also the fact that sometimes it can be argued that some approaches to two-factor authentication are not indeed two-factor and more like two-step. I would say, the most debated discussions are around implementations based on cell phones, because even though a cell phone is something you have, sometimes you authenticate by reading a piece of information from the phone and in theory that means that it's actually something you know.
Having said that, and not wanting to a be a terminology purist, any means that provide additional protection besides just a password are a huge improvement. You can check Getting started with Multifactor Authentication for a further read.
The difference between two factor authentication and two step authentication is method used to verify the user's identity.
Two Factor requires the user their password then another one time password
This one time password is either a code received on their mobile device, or perhaps a code generated from an app like Google Authenticator.
Two Step Authentication requires the user to enter their password and the next step the user is in possession of the token or cookie on their computer
If the cookie or token doesn't exist - they are then have to enter a One Time Password that they receive via SMS, Email or use an Authenticator application.
Token cards display a number that changes periodically, perhaps every minute. Each such
device has a unique secret key. A human can prove possession of a particular such device by
entering the displayed number into a computer system. The computer system knows the
secret keys of each authorized device. How would you design such a device?
I believe this kind of authentication scheme is part of "two-factor authentication". In many popular 2FA solutions the user owns a small calculator-size device with a preconfigured PIN key. Upon entering the PIN, a One time password (OTP) is generated.
By entering the generated password, associated with his username, the user "proves" he has the device and knows the PIN code. Aladdin's safeword is such a device, popular in corporate/VPN/WifiPEAP environments.
It's also nowadays centralised and OTP are now often sent through SMS.
If you google around for the "How to implement two-factor authentication", you'll find numerous good articles. The topic is complex and involves many different technologies.
You can try this article for instance.
In the token device:
A stable clock with maximum deviation of 10s/year (can be done using quartz crystal oscillator), synchronized to UTC.
A public key stored individual to each device
Some random saltID, which also serves as the user identification value, so it should have reasonable length
A hash function
The number the token shows is generated by combining the saltID with the current time, hashing the value and encrypting it with the public key.
Upon login the authentication system reperforms the steps of the authentication token, minus of the public key encryption (i.e. it just computes the hash). The crypted hash is decrypted and compared to the calculated hash. If both match the token is accepted as valid.
The better authentication tokens have some numeric input, where the user can enter his PIN code, for protecting against loss or theft.
I've been given the task of finding and evaluating some authentication libraries for use in one of our products and one of the selling features being pushed by some solutions is "two-factor authentication".
What is this method and how does it work? Are there better methods (such as three-factor authentication, I guess)?
Two factor authentication is using two factors to authenticate a person (or sometimes a process).
This might be a PIN number (something you know) and a debit card (something you have).
There are many authentication factors that might be used:
Authentication factors apply for a
special procedure of authenticating a
person as an individual with
definitively granted access rights.
There are different factor types for
authentication:
Human factors are inherently bound to the individual, for example
biometrics ("Something you are").
Personal factors are otherwise mentally or physically allocated to
the individual as for example learned
code numbers. ("Something you know")
Technical factors are bound to physical means as for example a pass,
an ID card or a token. ("Something you
have")
From wikipedia.
Which factors you choose depend on the type of access required, security needed, cost, and especially what people are willing to put up with.
People get irritated with strong passwords that change every 4 months, so you might find employees happier with laptops that have fingerprint scanners and they can use a weak password and a fingerprint - two factor authentication may be easier for users.
But others might not like the privacy implications of biometric security and would rather carry around a keychain device that produces numbers which are typed in along with a password.
High security situations may require all three factors - something you have such as a card, something you are such as retinal imaging, and something you know such as a password.
But the costs and irritation go up as you add more levels.
-Adam
"Are there better methods (such as three-factor authentication, I guess)?"
The issue isn't simply more factors. It's a better mix of factors.
Passwords are easily lost and compromised. People write them on stickies and put them on the bottom of their keyboards.
Other non-password factors are part of the mix. For browser-based apps, you can use IP address, and other PC-specific material that floats in as part of the HTTP headers. For desktop apps (like VPN connections) independent key generators or plug-in USB readers might provide additional factors.
Its when two (or more) different factors are used in conjunction to authenticate someone.
For example, a bank might ask you for your account number and pin number. And sometimes, like when you call call centers, they might ask you for additional factors such as name, dob, phone number, address etc.
The theory is that the more factors you can authenticate against, the higher the probability that you are dealing with the correct person. How well it works and how much more secure it is is debatable in my opinion...
Factors include:
Human factors are inherently bound to the individual, for example
biometrics ("Something you are").
Personal factors are otherwise mentally or physically allocated to
the individual as for example learned
code numbers. ("Something you know")
Technical factors are bound to physical means as for example a pass,
an ID card or a token. ("Something
you have")
See: http://en.wikipedia.org/wiki/Two-factor_authentication
I'll take this from a completely different tact. All these answers are correct, of course, but I want to broaden the topic a bit - to think about where & when to apply two-factor authentication. There are three areas where strong authentication can be used: session authentication, mutual authentication and transaction authentication. Session auth is what most people think about when they think about 2FA. But imagine if people only had to use an OTP when making a banking transaction. The attack surface goes from "when logged in" to "When making a transaction", which is much smaller. if the transaction authentication uses a public key system to sign the tx, then all the better.
Mutual authentication is some system that attempts to thwart MiTM attacks. You can think of the little pictures some banking sites use, but they are totally ineffectual because there is no crypto involved. here's how we do mutual auth, by validating the site's ssl cert for the user: http://www.wikidsystems.com/learn-more/technology/mutual_authentication/. There are other ways to do the same thing, of course.