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.
Related
I am working on authentication system that works only with public-private keys for authentication. No email, no phone.
I need to pick "proper" algorithms for user authentication and account recovery.
https://diafygi.github.io/webcrypto-examples/
user_id - public-key generated by user's browser during sign-in. Should be short and not include special chars. Will be used more as unique identifier for the user between different systems. Also used for account recovery. Could be for ex. last 20 bytes of the public address, as long as the chance of collisions is very low.
login_pub_key - generated by user`s browser. User will use the private key for authentication.
recovery_pub_key - generated by user's browser. User will use the private key together with user_id private key for for account recovery and to change login_pub_key.
Do you have any suggestions what would be suitable for these 3 cases?
I am struggling on thinking how to do an auth system which allows arbitrary clients that share the same source code but have random uuid based identifiers to authenticate. A requisite for that is that the clients must not need human interaction to login to that server, think of it kind of an automatic IoT device that needs to login to a central server but can't receive user input.
For my use case, I don't need it to be a very secure system. But at least it would be nice to have some kind of impediment to attackers.
My first approach is using the identifier uuid as a username, and a function that hashes the identifier with other dynamic values along with a secret, but that seems to me a bit hacky... The hash generated must be constant for each device.
The clients can't use non-simple hashing/encryption methods. Here's a list of things they can compute: MD5 hash, SHA1 hash, XORs between two base64 strings, SHA256 hash and ARCFOUR.
The server, however, can compute any encryption/hashing algorithm, and the identifier of the device is public and can be accessed by anyone. However, the source code is private and the communication is made with https.
Any ideas of how to achieve this with a better auth method? (Taking into account these restrictions)
You say the IoT device cannot receive user input. Can it display or communicate anything to the user? If so, you could consider the OAuth2 device flow.
Your IoT device would be polling the authorization server.
You can use the browser on your phone or computer to authorize the IoT device.
We are currently tasked with implementing a (preferably simple) authentication system for a mobile application communication with a RESTful API. The backend has user-specific data, identified by the user's phone number. I am trying to understand more about security in general, the different methods there are and why they work the way they work.
I thought of a simple authentication system:
The client sends a verification request to the api which includes their phone number and a generated guid.
The server sends an SMS message to the phone number with a verification code.
The client verifies their device by sending their unique guid, phone number and verification code.
The server responds with some kind of access token which the client can use for further requests.
I have the following questions:
Are there any major flaws in this approach?
Assuming we use HTTPS, is it secure enough to send the data otherwise unencrypted?
Can access tokens be stored on mobile devices safely so that only our app can read them?
Anything else we haven't thought of?
We already figured that when the mobile phone is stolen or otherwise compromised, the data is no longer secure, but that is a risk that is hard to overcome. Access tokens could be valid temporarily to minimize this risk.
I am assuming this approach is way to simple and there is a huge flaw somewhere :) Can you enlighten me?
There is a flaw. The system is susceptible to a brute-force attack.
Suppose I am an attacker. I will generate a guid for myself and send it along with some arbitrary phone number.
Next, I will just bruteforce my way through the possible SMS codes - if it's 6 digits, there's only 10^6 combinations. The bruteforce will be a matter of seconds - and then I will gain acess to the data of the person having this phone.
Also, as was pointed out in the comment by Filou, one can force you to send you arbitrary number of SMS, effectively making you sustain a financial loss at no cost.
There's also no valid defense from this attack:
If there is limited amount (N) of attempts for a given UID, I will
re-generate the guid every N attempts.
If there's a limit of requests per phone per amount of time, I can execute a DoS/DDoS attack by flooding every possible number with fake requests - hence, noone will be able to perform any requests.
A login/password or certificate authenication is mandatory before an SMS. Also:
Never use things like GUID in cryptography/security protocols. GUIDs are deterministic (i.e., knowing one value, you can predict future ones). Use crypto-libraries built-in functions for generating random streams
Never try to design security protocols yourself. Never. There's an awful lot of caveats even SSL 1.0 creators fell to - and they were sharp guys, mind you. Better copy common and proven schemes (Google's auth is a great example).
The approach you mentioned will works fine. Client will initiate a request with the phone number and a random id, server returns a verification token to the device. The token is one time use only with a set expiry. Then client will send the phone number, the random token used before and the validation token, which the server verifies. If valid, server sends a session token (or auth token) or similar which can be used for authentication. The session token can have a time out set from the server.
You did not mention if it's a web app or not. If it's a web app, you can set a https only session cookie from the server. Otherwise, you can store it locally in the app's local store. In usual case, apps cannot read private data belonging to other apps.
All communications must take place using HTTPS. Otherwise the whole scheme can get compromised via sniffing for traffic, because in the end you are using the auth token.
I've been curious as to how google generates one time log in tokens on an iPhone app without comminicatig with the server when the token is Assigned. The token changes every ten seconds. How does google know what the right token is? I disabled data and it still works.
Thanks
it uses your unique key during setup as well as a special sequence/algorithm (that's part of the authenticator program (in your case, the iPhone .app)) to generate a special key. As part of the key-generating process, it also uses the current time on your iPhone to match up with the computer time you are logging in from.
remember a verification code, wait for the current code to expire, and continue logging into your google account on your computer with your previously memorized code. it will still work. try changing the time on your phone by 20 minutes off or something, and use a newly-generated code, it will not work.
it works similar to the HSBC security dongle keychain thinggy (for online banking) if you have one.
Google Authenticator generates OTPs based on the secret key. The secret key (seed) is 16 or 32 character alphanumeric code. In the process of token enrollment, the server generates the secret key and shares it with your phone via QR code (or you can enter it manually). For example, when TOTP algorithm is used, server and Google Authenticator know the seed and the current time and based on this information they generate the same one-time passwords (OTPs) at predetermined intervals. So the key elements are the secret key and time. Google Authenticator doesn’t require any internet connection or mobile network.
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.