Recently, I was implementing 2FA using TOTP according to RFC 6238. What caught my attention were the default values: 30s time step, epoch as the start time of counting, and especially the widely used parameters (not directly recommended by the RFC): secret represented in Base32, codes of lengths 6 and HMAC-SHA1 as the underlying algorithm. My questions:
Is it reasonable to assume changes in widely used implementations, using the parameters above? This implies implementing a way to customize the parameters instead of hard coding the default values.
Are there any known plans to "upgrade" the used parameters by widely used client implementations, e.g. Authy, 1Password, Google Authenticator etc.?
Answer on the first question depends on your needs. If you have implemented 2FA on your server and looking for some app to generate codes on a client side - you just need to choose an app which already supports working with different parameters, so in this way you can be sure that next app update won't broke your auth system.
As for the common realization: most of the auth servers use 6-digits codes using 32-symbols seeds in Base32 and SHA1 as a hashing function, but I've met some systems with SHA-256 and 52-symbols seeds.
Related
I'm wondering how Application Insights infers the client's device model because the Microsoft docs do not state what method is used. Obviously, they must pull it from the client's user agent string, but do they use some sophisticated ML algorithm to classify the device model? Or do they simply apply some regex based logic?
I'm asking because I'm not sure how reliable this information is and I'm considering to use it as normalized input for an own multi-class classifier to categorize the user agents into four classes (mobile, desktop, tablet, unknown).
Application Insights uses an OSS component called UA-Parser. This uses RegEx to parse the UserAgent string to derive the device information used for device.model. The parsing occurs in Application Insight's ingestion service.
The GitHub project looks like this one:
https://github.com/ua-parser/uap-ref-impl
My case is that I want to make the data protected even from people who have access to the back-end (the keys store), so they couldn't read it without the user's (represented by the client app, in my case the browser) assistance.
One option is to have the decryption keys stored on the client and passed with each request which sounds pretty messy to me and i'm not sure I want my keys to wander around the net like this. What I imagine though is that the client will keep some token (it might be a password the user knows) and the decryption can't happen without it.
I thought about using the purpose string for this, I have the feeling it is not a good idea since its main purpose is isolation. On the other hand it is part of the additional authenticated data used for subkey derivation. (based on this article https://learn.microsoft.com/en-us/aspnet/core/security/data-protection/implementation/subkeyderivation?view=aspnetcore-2.1#additional-authenticated-data-and-subkey-derivation).
I came across some examples that create their own symmetric encryption with a lower level classes. (like this post Encrypt and decrypt a string in C#?). Since I'm not an expert in this area I would like to use as much build in classes as possible.
What is the recommended way to achieve what I need with the classes from the Data Protection API? (I'm using .net core 1.1 on Ubuntu)
I'm very much fascinated by RSA SecurID and similar 2-factor systems.
I have been through many articles including this one: https://security.stackexchange.com/questions/9584/can-the-numbers-on-rsa-securid-tokens-be-predicted
My question is, since RSA's algorithm uses a "seed" and the numbers therefore generated are in a "series".
What if I generated a token on the secure device when the server asked for it and instead of using that token I pressed the button again to generate another token?
Would this not cause a "mismatch" in the series running on the device and on the server?
It would have been easier if the logic just depended on the clock and device serial or so but since there are seed and random numbers involved, I wonder what happens if you skip a token or two?
Thanks.
As I understand it, the SecurID tokens don't use a "rolling counter" — the token is generated solely from the device serial and the current time. Also: in the RSA SecurID tokens I've seen (admittedly limited), the user doesn't press a button to generate the token; instead the token is constantly visible on the screen. Thus the token generated doesn't get out of sync (in the sequence) with the server, except for the possibility of clock drift on the token side (usually servers use NTP and so their clock drift is negligible).
However, the typical solution for clock drift problems is to store a "drift" parameter on the server, on a per-token basis. This drift parameter can be updated manually (for maximal security but also maximal pain) or one can check the surrounding intervals on the server side. For example, if I log in now, you might check the server's current sixty-second interval, the previous one, and the next one all for validity, and if the previous/next are valid, you store that drift for the token.
On the other hand, there is an algorithm that suffers from the problem you've described: the HMAC-based One-time Password Algorithm. It uses a rolling counter that is supposed to be synchronized on both the server and the token. So, if you have a HOTP-based authenticator and you press the token generate button many times, you will cause it to fall out of sync, and manual intervention is required by the server administrator.
A similar solution can be enacted as above: check the next few values of the counter, say counter+1, counter+2, counter+3, etc., and store that as a 'drift' parameter. Depending on how far out one checks, the token could eventually go out of sync, if it were pressed repeatedly.
A variant of HOTP that fixes is the problem is the time-baesd version, which uses a "time counter" instead of a real counter. This is what Google Authenticator uses. Here, you still have the clock drift problem, with the same solution as above.
If you are fascinated by the OTP systems then you should read RFC 4226 which describes HMAC-Based OTP algorithm and RFC 6238 which describes TIME-Based OTP algorithm as these two algorithms are used by the most of the OTP solutions available today.
If you are interested also in the recent developments in the area of two factor authentication then you should visit website of FIDO Alliance and take a look at their specs too.
Ok after a LOT of researching, I've settled on using bcrypt (feel free to comment) to hash and store passwords in my phonegap app.
A few days ago I stumbled upon Bcrypt.net and it seems 'good enough' to me (again, feel free to comment). So, my question is what other alternative implementations of bcrypt are available in C#? Are there any SERIOUS flaws in the implementation of Bcrypt.net?
My security model is basically going to look like this:
User enters his pin/password/passphrase on the client
This is sent to my .net app over secure SSL (so basically send in plaintext from the client)
Use a library like bcrypt.net to hash the password and do the storage/comparison
Is there anything else that I really need to consider here?
Any help will be greatly appreciated.
Glad to see somebody here who did some research.
I haven't seen any good reasons why you should not use bcrypt. In general, using either bcrypt, PBKDF2 or scrypt on the server to provide a good layer of security.
As always, the devil is in the details. You certainly require SSL, if possible TLS 1.2 using AES encryption. If you cannot do this, make sure you don't allow much else than username/password + necessary HTML in your connection.
You should make a decision on the character encoding of the password. I would advice UTF-8, possibly narrowed down to printable ASCII characters. Either document the character encoding used or store it somewhere in the configuration.
Try to store all input parameters to bcrypt together with the "hashed" password. Certainly don't forget the iteration count. This makes it easier to upgrade to higher iteration count when the user enters his/her password later on. You need to generate a secure random salt of 8-16 bytes to store with the password.
In addition, you may want to apply an additional KBKDF (key based key derivation scheme) to the output of any of above PBKDF's. This makes it possible to use the output of bcyrpt for additional keys etc. KBKDF's work on data with enough entropy, so generally they take little time (e.g. use a NIST SP 800-108 compatible counter mode KDF). I guess this should be considered "expert mode".
The major reasons for doing password hashing are:
a. Password plaintexts are not transmitted over the wire (primary).
b. Password plaintexts are never persisted on server (secondary)
So with your setup - you're not doing a. and instead relying on the SSL. I think you should still hash on client side if possible. Leaves you more margin for future changes and in general, passwords deserve higher security / protection than your content data.
Also, i don't know what kind of server apps / extensibility you may support, so again insulating the password(s) from code might still remain an additional issue.
As far as the actual algo / util for doing the hash - i don't have the security expertise :)
You're good with bcrypt.
Great research from a cracker: https://crackstation.net/hashing-security.htm#faq
Additional verification from sophos: http://www.sophos.com/en-us/medialibrary/PDFs/other/sophossecuritythreatreport2013.pdf
bcrypt is also part of the c# libs:
http://msdn.microsoft.com/en-us/library/windows/desktop/aa375383(v=vs.85).aspx
I am looking for a programmatic way to generate consumer key/secrets for HMAC-SHA1 to be used by clients invoking our API over OAuth. Any pointers to existing implementations would be highly helpful.
Secrets are best when generated from random data. That way there is no external data which could help an attacker deduce or guess part or the entire key. Of course, it depends on how much protection your secret key needs. Java includes some random number generators in java.util.Random (since JDK1.0). If you don't have backward compatibility issues, Java 6 has java.security.SecureRandom which meets FIPS 140-2 requirements. The Java libraries are not truly random, but it is probably good enough for most applications. If you need better random data, you should go for a hardware-based random generator.