So as part of a project, I want to implement a two step authentication system (in rails)
I understand the principles of it,
=> Client: Username and password
<= Server: Generate PIN code and send it to client via SMS/email
=> Client: enter PIN
<= Server: authenticate client as normal
Now what I want to know is in a web based application such as rails, the PIN needs to be kept secret at every point, so when redirecting from the username/password part to the PIN part, I need to keep the PIN code secret while passing it over to the next part of the system (the PIN part)
Is the only decent way to do this, by temporarily storing the PIN in the database alongside a user ID?
No, not quite that.
There are two (most used) types of one-time passwords (OTPs, PINs in your terminology):
Time-based
Counter-based
Time-based ones (TOTP) generate some number based on current time (for example: number of 30-second intervals from 1970.1.1 00:00) and some shared secret. When receiving such one-time password, server generates one on its side and checks whether it's correct.
In counter-based OTPs, you have a counter and a secret key stored in database near user ID, and it is used to generate the OTP. It can be incremented based on login attempt.
Time-based tokens are usually better, as they don't require counter synchronization (time synchronization is usually easier). Best example of this is the Google Authenticator, which implements standard TOTP from RFC6238.
There's one Ruby OTP library which claims compatibility with Google Authenicator, you may want to try it out: link
Can't vouch for its security and/or quality, but it looks promising.
Related
I am trying to implement expiring to the activation link I send to the user's email when they register a new account.
The link should expire after 24 hours if the user doesn't click on it.
Up until this point I am able to send the link to the user's email upon registration, the link looks like this 'http://localhost:3000/auth/activate/${verificationKey}', everything works smoothly.
But like I said, I want the link to expires after 24 hours and I just don't have any idea of how to do it.
From what I've gathered so far I think one way to do this would be to delete the verificationKey value from my User entity/model after 24 hours, then if the verificationKey value is falsy I need to send another link to the user.
Now my question is, how do I check if a value (in this case user.verification_key) has been generated for over 24 hours?
This is the relevant code to register a new user:
const user = new User();
user.username = username;
user.password = await bcrypt.hash(password, salt);
user.is_verified = false;
user.verification_key = cryptoRandomString({
length: 10,
type: 'url-safe',
});
Some people have suggested to use Redis for this, which I don't know anything about other than it's a in-memory store, and while I'm ok reading more about this tool, I would like to know if there are other ways to do this. I don't know if by installing Redis I would need extra configuration for the server when I host my app, I'd like to avoid that.
Since you already have some database set up, it makes sense to store some verification key and an expiration time for it. You don't need to actually delete that verification key... just need to store when it expires.
Perhaps you have a separate model for RegVerificationKey, with fields key (randomly generated string), expiration (set to a date/time 24 hours after you create it), and userId (the ID of the user this is associated with). Create this key. When you go to activate, just check to see if there is a key associated with the requested user that hasn't expired yet.
Some people have suggested to use Redis for this
No need here, you already have a database you can put data in.
I would like to know if there are other ways to do this
There's an alternative, where you cryptographically sign your URL. Basically, you would store the key and its expiration data in the URL itself, and include some calculated proof that you (the person with the private key) created this URL. When your system receives this URL, it can verify the URL was signed correctly without even having to consult a database. This method can be complicated and probably isn't useful in your case. I'm just mentioning it here as an alternative. Check out JWT for one possible implementation: https://jwt.io/
Recently I was needed to implement this kind of implementation in my web application. So I just followed the below points to achieve it.
1- Create the URL (web link) and append the current date and time along with an encrypted key which you would store in the database as mentioned below.
2- Create a column in the database table (the table where you store any user specific details) to store a randomly generated key which you have encrypted and appended in the URL.
3- When you would receive this URL on server you would check the encrypted date and time in the URL and would decide whether it is still valid depends on your criteria of retaining a link (e.g. 24 hours)
4- Next you would decrypt that key in the URL that you have appended in it at the time of creating it and would match it with what you have stored in the table.
So by implementing above logic you could achieve the desired functionality.
Hope its useful for any one who wants similar type of implementation
I understood that you already found a solution, by storing two fields in the database: one for the key and another one for he expiration timestamp. Everything depends on the use cases and it is definately one way to do it. However I will explain Redis and JWT as a solution in comparison to yours.
Redis is an in-memory datastore (that also allows persistence to disk) as you pointed out and I think the reason why people suggested it is, that you can define an expiration time for a record. Redis will remove that record automatically for you then. Reference: https://redis.io/commands/expire
Redis would take the work off of your shoulders to check if the 24hrs already passed. If you can’t fetch the key anymore, the key probably expired. Another benefit of Redis is, that is super quick compared to your normal database query. But if you only need it for the activation link, which is a one-time-action for the user, the time benefit is negligible. Also you would introduce a new technology just for that use case.
#Brad already suggested using JWT (Json Web Token) instead of implementing your own token solution and I would also suggest that for the following reasons.
A JWT is a self-contained token consisting of three parts: Header, Payload, Signature. The header contains the name of the algorithm that was used to create the token. The paylod contains some standardized fields (e.g. creation date, expiration date, subject the token was issued for like username) and you can also add custom fields. The third part is a signature that ensures that no one changed the payload after it was issued by your token service.
Self-contained means that the token contains everything to validate it, including the expiration timestamp. In your case the expiration time is not part of your token but stored in the database. If you create another microservice that needs to verify your token, that service needs to contact your main service which contains the logic to check the expiration database field.
With JWT the Microservice would only need to know the secret key that was used to sign the token and then you can just import some standard JWT library to verify the token. These libraries validate the signature as well as the expiration timestamp which is an optional field in the payload of the token.
By the way, the payload can be read without knowing the secret key from the signature. So it is even possible to read the payload for example on client side to check the expiration time.
With your solution you have additional database calls, which are potentially slow. For an activation link that is acceptable, but for tokens with recurring use within a short timespan (i.e. API requests that require authentication) additional database calls should be avoided. Also you need to implement token generation and verification yourself, whereas JWT provides standard libraries. This is a benefit when you want to have another Microservice in Java instead of NestJS for example. You can quickly knit them together by using standard libs instead of porting your implemtation or being forced to decide for a centralized token verification service.
One limitation of JWT you have to workaround yourself, is the use case where you want to have a „one time token“. You can only define an expiration date but you can not say that a token can only be used x times. Here you need a centralized service again, which keeps track of how often a token was used (by making use of some datastore) and all other services around need to contact that service.
A good starting point for JWT with NestJS is the official NestJS documentation.
I have such requirement about changing the users secret for every session for generating OTP. We decided to use TOTP as our algorithm to do so. We are sending OTP in SMS to the user for authorization verification (no need to generate OTP at client side).
TOTP = HOTP(WhereSessionCalculate(SecretKey), TC)
So, Is it good practice to change the secret of an user session wise. If not then what are the consequence that can possibly arise. Please explain and let me know if more information needed.
The basic premise of two-factor (or multi-factor, to be more accurate) authentication is to supplement the normal username/password combination - these are things you know - with one or more additional factors of a different type. Most commonly used are what you have (e.g. your cellphone, with a Google Authenticator app or an RSA, Gemalto etc. token) or something about what you are (biometric data such as iris, fingerprint etc.)
Someone can learn a username and password from shoulder-surfing (easy if the password is short), even sniff it from an insecure network connection (hope you're using SSL with AES256 or somesuch to encrypt the sessions to your app!) but the addition of 2FA stops that.
So let me some back to your question and whether your approach is accretive to the security of authenticating your users . Once the user's OTP key is set and stored in the user's record in the database, and that key is used to seed the TOTP generator, what would having the user re-seed with a new key accomplish? Yes, generating a OTP code and sending by SMS verifies that the person logging on has their phone with them at that very moment, but then so would using Google Authenticator; moreover, and I betray my Apple fanboi bias here (!) incoming SMSes are displayed on the lock screen of my iPhone, which would also therefore display your OTP, whereas to access the Google Authenticator app I have to unlock my phone with my PIN.
Also bear in mind that most systems are compromised at a network or system level and whole databases of usernames and passwords stolen to be cracked - compromising a single user's access isn't generally worth the trouble, unless you have a very high value asset attracting the attention of state actors!
Having explored the issues here for my own app I've gone with a username and password initial login (minimum length 20 characters to perplex rainbow tables, but with no stipulation on complexity or frequent changing), maximum number of attempts before locking the account for an increasing amount of time for failed logins, and a secondary login using Google Authenticator (as it's free, runs on iOS, Android and BB10, and is pretty easy to use). To improve on this I would consider biometrics but my application is commercial not military etc. so what I have is quite enough for my assessment of the risk.
I hope that helps you work out the best approach for your application.
I'm working on a system that will require a user to log in on a device using an account that they created on a website. Authentication will be over HTTPS, so that is not an issue. The application running on the device will allow in-app purchase using a credit card linked to their account, so it's important that the login credentials are secure enough that it would be difficult to attack using brute-force. The only problem is that the device that the user will be using will have limited user input capabilities (essentially, arrow keys and a selection button).
In this case, a typical username/password may be too cumbersome to enter, also requiring the development of a on-screen keyboard that is navigable via the arrow keys. Users would likely end up creating simple passwords that are easily cracked. However, once logged in, the user will be using an access token behind the scenes so they may not need to enter their password very many times.
The first step is that the user will need to enter their username or ID number. Using a number may be easier to enter, but also easier to guess. I'm open to suggestions in this area as well.
Next is the process of entering a "password". So here are a few ideas that I have, but I'm not a cryptography expert so I don't know how to gauge the level of security.
User must first register the device. This might be a step that I require anyway, for extra security. The device would generate a key that is sent to the server and stored with the account. The key would be required when performing future authentication requests. The user would need to log into the website to approve the device. The device isn't going to have any sort of identifier, so unless you log in soon you wouldn't know if it was your device or someone else trying to spoof you. It would be nice to be able to create some sort of additional identifier, maybe a short code, phrase, or an image is displayed so you can know it's the same device that you just tried to register.
Since entering a text password may be too difficult, as long as the device is registered, maybe a 4 digit passcode can be used when confirming in-app purchases. This may be nice anyway to prevent other users of the device from using your account without your permission. However, if they are watching you enter your passcode, then it's not really good for that purpose anymore.
If registering the device is not necessary, instead of logging in with a text password, maybe the user is presented with images or phrases as options and they must choose the right combination of images/phrases that matches their account.
That's all I've got so far. What are your thoughts? How can I create an easy, but secure, login when in-app purchases are involved?
I have been dealing with limited user input capability scenario. Would you describe the platform your app running on?It helps to fit the solution according to the platform security model.
Update: I hope you are not considering multi-user per device scenario. So, I am assuming that there is one user per device. The second assumption is the device may have a unique serial number that can be accessible through some APIs and the serial number is registered on the server in advance.
At the initial stage, the user generates a random key through the device select button and the app confirms the success of key generation probably it display the serial number (the user may need to register the serial number for latter configuration). Behind the scenes, the app sends the new key with its serial number to the server. The server updates its serial number with the random key in the database entry. The device can block further key generation or may allow until it is finally configured with a dedicated user. The device also persist the serial number with the random key in the local database/file. The user is then login to their account through a web interface to configure the device. For logged in user, the server presents a list of available devices and the user can choose a specific one that belongs to her/him and set four digit pin code. The server performs the following:
Link the user account, the serial number, the random key (the one the device sent at the beginning).
generate a token
generate a key using pin code and the random key as a salt through Password based key derivative algorithm (PBKDF2)
encrypt the token using the key derived at step 3
Update database user row with the cipher token.
The user can sync the cipher token through the device select button. To unlock the app, user must enter the pin code through a simple numeric screen. The app uses the pin code and a random key (persisted at the beginning) and generates a PBKDF2 key and decrypt the token. PBKDF2 helps us to slow down the brute force a bit but it is possible to enforce time based or attempt based lockout as well. For instance after some trail, the app can drop the user credentials and force the user to configure from the scratch.
On the current project I'm working on, we have the following problem.
Our software is a Location Based Services platform and applications can connect and use our services through our exposed webservices using SOAP. Until now our platform was only used by internal applications, but now we would like to open it for third party applications. For that we need an authentication mechanism.
Because of our customers' infrastructure and load balancing solution, we cannot use HTTPS. The original idea was that applications can just use HTTPS and send the password we authenticate.
A solution would be the next:
The application has the password. The application generates a random string (salt) and creates a hash. Then the application creates an HTTP request sending the hash, the salt and a timestamp. This three is enough for us to authenticate, as we can generate the same hash and compare.
My problem is that for this we need to store the password in our database in clear text, because we need to do the same process using the given salt so we can compare the result and authenticate the application. Storing passwords in clear text is unacceptable.
Do you know about any authentication/access control mechanism that would fit this situation? Generally, do you know about any good books/sources about application authentication/access control mechanisms?
Any help is highly appreciated. Thanks in advance!
The application (client) can hash the password two times. Note that the server should generate the other random salt, not the client! Otherwise the attacker can log with this hash also. You can also make it safer by storing password specific salt in the database.
The protocol:
0) servers retrieves salt for that particular password from database, generates salt2, and sends both to the client
1) client sends hash(hash(password, salt), salt2, timestamp) and timestamp.
2) server retrieves hash(password, salt) from the database and compares.
Note that if you are on the network where attackers can not only sniff, but also modify the traffic, as Paulo pointed out, you should sign EVERY message: hash(hash(password, salt), salt2, timestamp, message) and check it at server. (E.g. for the case when the attacker could modify the message to contain delete command...)
Note that there is still a problem when user needs to SET/CHANGE the password safely. You cannot do it safely with just hash function over unsafe network, you need some kind of cipher/decipher.
Also note that the slower the hash function is, the safer (because of the dictionary attack). If you don't have access to special slow hash function, you may also call normal fast hash function 100000 times.
Instead of inventing your own solution, you should use an established one. SOAP has support for cryptographic authentication such as WS-Security - see Craig Forster's comment on this answer for suggestions.
The best choice in other cases is usually oauth; it provides both authorization and authentication, and deals with a lot of cryptographic issues that you're not likely to spot when building your own.
Using an authentication solution which does not contain an integrity check of the whole message (or stream) is insecure.
While the hashing solution originally proposed by Thomas T. (hash(hash(password, salt), salt2, timestamp), where hash(password, salt) is stored in the database, and salt2 is newly generated) makes sure than an attacker can't get the password (or any data which will be useful for logging in after the timestamp expires), it alone does not prevent an active attacker to hijack the session after the authentication, and send any SOAP requests wanted (and intercept the responses).
What would be needed here is some way to make sure that no data is changed. This is known as a message authentication code (MAC). The usual definition of a MAC includes some (shared secret) key and the message as input, and an authentication token as output.
The usual way to use this would be to do some authenticated key exchange at the beginning of the communication (using either a shared secret or some known public key), and then use a part of the now shared secret as the MAC key, which is then used to authenticate following messages.
(Doing this then essentially is a reinvention of SSL/TLS (or parts thereof), potentially doing the same mistakes again.)
If you have only one message to send, you can instead use the MAC as a kind of symmetric signature, using the password hash (salted and generated with a slow hash function) as a MAC key.
Another way to view this would be to take the message to authenticate as an input to the outer hash in Thomas T's authentication scheme. (Make sure to authenticate everything that is worth authenticating.)
Many users – myself included – would like the security of having everything they do on a web service encrypted. That is, they don't won't any one at the web service to be able to look at their: posts, info, tasks, etc...
This is also major complaint in this discussion of an otherwise cool service: http://news.ycombinator.com/item?id=1549115
Since this data needs to be recoverable, some sort of two-way encryption is required. But unless you're prompting the user for the encryption key on every request, this key will need to be stored on the server, and the point of encrypting the data is basically lost.
What is a way to securely encrypt user data without degrading the user experience (asking for some key on every request)?
-- UPDATE --
From #Borealid's answer, I've focused on two possibilities: challenge-response protocols, where no data (password included) is sent in the "clear", and non-challenge-response protocols, where data (password included) is sent in the "clear" (although over HTTPS).
Challenge-response protocols (specifically SRP: http://srp.stanford.edu/)
It seems that its implementation would need to rely on either a fully AJAX site or using web storage. This is so the browser can persist the challenge-response data during encryption and also the encryption key between different "pages". (I'm assuming after authentication is completed I would send them back the encrypted encryption key, which they would decrypt client-side to obtain the real encryption key.)
The problem is that I'm either:
fully AJAX, which I don't like because I love urls and don't won't a user to live exclusively on a single url, or
I have to store data encryption keys in web storage, which based on http://dev.w3.org/html5/webstorage/ will persist even after the browser is closed and could be a security vulnerability
In addition, as SRP takes more than one request ( http://srp.stanford.edu/design.html ), there needs to be some persistence on the server-side. This is just another difficulty.
Traditionally
If I'm ok transmitting passwords and data in the clear (although over HTTPS), then the client-side issues above are not present.
On registration, I'll generate a random unique encryption key for the user, and encrypt it using their password and a random salt.
In the database, I'll store the user's password hash and salt (through bcrypt), encrypted encryption key, encryption key salt, and encryption iv.
After an authentication, I'll also need to use their password to decrypt the encryption key so that they may view and enter new data. I store this encryption key only temporarily and delete it when they explicitly "log out".
The problems with this approach is that (like #Borealid points out) evil sysadmins can still look at your data when you are logged in.
I'm also not sure how to store the encryption keys when users are logged in. If they are in the same data store, a stolen database would reveal all data of those who were logged in at the time of theft.
Is there a better in-memory data store for storing these encryption keys (and challenge data during an SRP authentication)? Is this something Redis would be good for?
If the data need to be recoverable in the event of user error, you can't use something like a cookie (which could get deleted). And as you point out, server-side keys don't actually secure the user against malicious sysadmins; they only help with things like databases stolen offline.
However, if you're running a normal web service, you've already gotten pretty lucky - the user, in order to be unique and non-ephemeral, must be logged in. This means they go through some authentication step which proves their identity. In order to prove their identity, most web sites use a passed credential (a password).
So long as you don't use a challenge-response authentication protocol, which most web sites don't, you can use an encryption key derived from a combination of a server-side secret and the user's password. Store the encryption key only while the user is authenticated.
If you do this, the users are still vulnerable to sysadmins peeking while they're using the service (or stealing their passwords). You might want to go a step further. To go one up, don't send the password to the server at all. Instead, use a challenge-response protocol for authentication to your website, and encrypt the data with a derivative of the user's password via JavaScript before uploading anything.
This is foolproof security: if you try to steal the user's password, the user can see what you're doing because the code for the theft is right there in the page you sent them. Your web service never touches their data unencrypted. This is also no hindrance to the normal user experience. The user just enters their password to log in, as per normal.
This method is what is used by Lacie's storage cloud service. It's very well done.
Note: when I say "use foo to encrypt", I really mean "use foo to encrypt a secure symmetric key which is then used with a random salt to encrypt". Know your cryptography. I'm only talking about the secret, not the methodology.
None of those other solutions are going to maintain the feature set requested -- which specifically wants to preserve the user experience. If you look at the site referenced in the link, they email you a nightly past journal entry. You're not going to get that with JavaScript trickery per above because you don't have the browser to depend on. So basically this is all leading you down a path to a degraded user experience.
What you would want, or more precisely the best solution you're going to find in this space, is not so much what wuala does per above, but rather something like hush.com. The handling of user data needs to be done on the client side at all times -- this is generally accomplished via full client-side Java (like the Facebook photo uploader, etc), but HTML/JavaScript might get you there these days. JavaScript encryption is pretty poor, so you may be better off ignoring it.
OK, so now you've got client-side Java running a Journal entry encryption service. The next feature was to email past journal entries to users every night. Well, you're not going to get that in an unencrypted email obviously. This is where you're going to need to change the user experience one way or the other. The simplest solution is not to email the entry and instead to provide for instance a journal entry browser in the Java app that reminds them of some old entry once they get to the website based on a link in the daily email. A much more complex solution would be to use JavaScript encryption to decrypt the entry as an attachment inline in the email. This isn't rocket science but there is a fairly huge amount of trickery involved. This is the general path used by several web email encryption services such as IronPort. You can get a demo email by going to http://www.ironport.com/securedemo/.
As much as I'd love to see a properly encrypted version of all this, my final comment would be that journal entries are not state secrets. Given a solid privacy policy and good site security semantics, I'm sure 99% of your users will feel just fine about things. Doing all this right with true security will take an enormous amount of effort per above and at least some design/UE changes.
You should look into the MIT project CryptDB which supports querying an encrypted database using a subset of SQL. (see the forbes article, mefi thread, or Homomorphic encryption on wikipedia)
There is the Tahoe-LAFS project for cloud storage too, which conceivably could be leveraged into a fully anonymous social networking application, one day in the distant future.
If you want to perform computations on a server without even the server being able to see the data, you may be interested in knowing about fully homomorphic encryption. A fully homomorphic encryption scheme lets you perform arbitrary computations on encrypted data, even if you can't decrypt it. However, this is still a topic of research.
For now, I guess your best bet would be to encrypt all posts and assign meaningless (e.g. sequential) IDs to each one. For a more in-depth discussion of how to encrypt server-side data with today's technology, look up.