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.
Related
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.
On the client device, a synced Realm can be setup with an encryption key that's unique to the user and stored on the device keychain, so data is stored encrypted on the client.
(related question: Can "data at rest" in the Realm Mobile Platform be encrypted?)
Realm Object Server and the clients can communicate via TLS, so data is encrypted in transit.
But the Realm Object Server does not appear to store data using encryption, since an admin user is able to access all the database contents via Realm Browser (https://realm.io/docs/realm-object-server/#data-browser).
Is it possible to setup Realm Mobile Platform so user data is encrypted end-to-end, such as no one but the user (not even server admins) have access to the decryption key?
Due to the way we handle conflict resolution, we currently are unable to provide end-to-end encryption, as you correctly deduced. Let's go a tiny bit into detail with regards to the conflict resolution.
In order to handle conflicts the way we do, we use something called operational transformation. This means that instead of sending the data over directly, the client tells the server the intent of the change, rather than the result. For example, when two users edit a text field, we would tell the server insert(data='new text', offset=0) because the first user prepended data at the beginning of the text field, and insert(data='some more stuff', offset=10) because the second user added data in the middle of the field. These two separate operations allow the server to uniquely resolve what happened, and have conflictless resolution of the two writes.
This also means that if we encrypt everything, the server would be unable to handle this conflict resolution.
This being said, that's for the current version. We do have a number of thoughts on how we could handle this in the future, while providing (some degree) of encryption. Mainly this would mean more work on the client, and maybe find a new algorithm that would allow us to tell the client the intent, and let the client figure out how to merge everything. This is a quadratic problem, though, so we're reticent to putting too much work on the client side, as it could really drain the battery.
That might be acceptable for some users, which is why we're looking into it. Basically, there will be a trade-off. As the old adage goes: fast, secure, convenient: pick two. We just have to figure out how to handle this properly.
I just opened a feature request around possibly using Tresorit's ZeroKit to solve the end-to-end encryption question posed. Sounds like the conflict resolution implementation will still cause an issue though, but maybe there is a different conflict resolution level that can be applied for those that don't need the realtime dynamic editing of individual data fields (like patient health data, where only a single clinician ever really edits a record at any given time).
https://github.com/realm/realm-mobile-platform/issues/96
So basically what i want to do is, let my app keep sending package/ receiving package so I know which people i met before. the sending data is easy: i just need a uuid to identify that this is my app, and a number or string to represent which user it represents. Now the question is, how can I make it secure? Let's say if anyone who can detect it, then he can mock a exactly same package and send out, then if he stand next to me, my app will believe that he is the user even he is not(he mocked).
iBeacon is absolutely not fit this requirement because its uuid/major/minor can be easily detected. One way i can think of is using BLE instead of iBeacon to writing the encrypting data in a service, then the question is can anyone else easily mock a service with the data he detect?
The typical solution is to combine the real identifier with a timestamp and encrypt the pair using a secret key. This produces an encrypted identifier that constantly changes and is worthless unless you can decode it. Once decoded, the timestamp protects against replay attacks -- it must be within a small interval from the current time for the decrypted identifier to be considered valid.
Obviously, this solution requires synchronized clocks on the transmitter and receiver.
The details of the implementation are more of an encryption question than a beacon question. And the devil is in the details.
Can't find any flowcharts on how communication works between peers. I know how it works in Radius with PAP enabled, but it appears that with MS-Chapv2 there's a whole lot of work to be developed.
I'm trying to develop a RADIUS server to receive and authenticate user requests. Please help me in the form of Information not code.
MSCHAPv2 is pretty complicated and is typically performed within another EAP method such as EAP-TLS, EAP-TTLS or PEAP. These outer methods encrypt the MSCHAPv2 exchange using TLS. The figure below for example, shows a PEAP flowchart where a client or supplicant establishes a TLS tunnel with the RADIUS server (the Authentication Server) and performs the MSCHAPv2 exchange.
The MSCHAPv2 exchange itself can be summarized as follows:
The AS starts by generating a 16-byte random server challenge and sends it to the Supplicant.
The Supplicant also generates a random 16-byte peer challenge. Then the challenge response is calculated based on the user's password. This challenge response is transmitted back to the AS, along with the peer challenge.
The AS checks the challenge response.
The AS calculates a peer challenge response based on the password and peer challenge.
The Supplicant checks the peer challenge response, completing the MSCHAPv2 authentication.
If you'd like to learn about the details and precise calculations involved, feel free to check out my thesis here. Sections 4.5.4 and 4.5.3 should contain all information you need in order to implement a RADIUS server capable of performing an MSCHAP exchange.
As you can see in the figure, many different keys are derived and used. This document provides a very untuitive insight into their functionality. However, the CSK is not explained in this document. This key is optionally used for "cryptobinding", i.e. in order to prove to the AS that both the TLS tunnel and MSCHAPv2 exchange were performed by the same peer. It is possible to derive the MSK from only the TLS master secret, but then you will be vulnerable to a relay attack (the thesis also contains a research paper which gives an example of such an attack).
Finally, the asleap readme gives another good and general step by step description of the MSCHAPv2 protocol, which might help you further.
Unfortunately i can't add anymore comments, the demand is for me to have 50 reputation.
To your request:
My lab enviorment is of SSL-VPN used with AS of RADIUS.
Constructed with the following 3 items:
End-User -> there's no 'client' installed, the connection starts through a web portal. client = web browser
NAS -> This is the machine that provides the web-portal(the place the End-User enters the Username & Password) AND acts as a RADIUS CLient, transfering requests to the AS.
AS(RADIUS) -> This is me. I receive the access-requests and validate the username & password.
So in accordance with that, what i receive in the Access-Request is:
MS-CHAP2-Response:
7d00995134e04768014856243ebad1136e3f00000000000000005a7d2e6888dd31963e220fa0b700b71e07644437bd9c9e09
MS-CHAP-Challenge: 838577fcbd20e293d7b06029f8b1cd0b
According to RFC2548:
MS-CHAP-Challenge This Attribute contains the challenge sent by a NAS to a Microsoft Challenge-Handshake Authentication Protocol (MS-CHAP) user. It MAY be used in both Access-Request and Access-Challenge packets.
MS-CHAP2-Response This Attribute contains the response value provided by an MS-
CHAP-V2 peer in response to the challenge. It is only used in
Access-Request packets.
If i understand correctly, and please be calm this is all very new to me, based on your flowchart the AS is also the Authenticator who inits the LCP.
And in my case, the LCP is initiated by the NAS, So my life made simple and i only get the Access-Request without needing to create the tunnel.
My question now is, how do i decrypt the password? I understood there's a random challenge 16-byte key but that is held by the NAS.
From my recollection, i only need to know the shared secret and decrypt the whole thing using the algorithem described in your thesis.
But the algorithem is huge, i've tried different sites to see which part of it the AS supposed to use and failed in each attempt to decrypt.
Since i can't ask for help anymore in this thread, i can only say this little textbox cannot fill the amount of gratitude i have for your help, truely lucky to have you see my thread.
Do email me, my contact info are in my profile.
Also, for some reason i can't mark your answer as a solution.
"is typically performed within another EAP method such as EAP-TLS, EAP-TTLS or PEAP."
Well...
RADIUS win2008 server here, configured to NO EAP, only MS-CHAPv2 encryption, to replace the PAP.
This is why alot of what you said and what i said wasn't adding up...
I'm not MITM, i'm the AS, and my NAS(the one who knocks) is the RADIUS_Client/Authenticator.
When the user enters UN&PW a random encryption, which i'm now on the look for, is created with MS-CHAPv2 and all of the above is irrelevant.
With the items received from the Authenticator which again are:
- Username, MS-CHAP-Challenge, MS-CHAP2-Response
The AS performs a magical ceremony to come up with the following:
-Access-Accept
-MPPE-Send-Key
-MPPE-Recv-Key
-MS-CHAP2-Sucess
-MS-CHAP-DOMAIN
This is from a working scenario, where i have a RADIUS server, a radius client and a user.
A NOT working scenario, is the one where i am the RADIUS Server(AS), cause that's my goal, building a RADIUS server, not MITM.
So all i got left is finding out what decryption algorithem needed for those and how.
I'm new to implementing encryption and am still learning basics, it seems.
I have need for symmetric encryption capabilities in my open source codebase. There are three components to this system:
A server that stores some user data, and information about whether or not it is encrypted, and how
A C# client that lets a user encrypt their data with a simple password when sending to the server, and decrypt with the same password when receiving
A JavaScript client that does the same and therefore must be compatible with the C# client's encryption method
Looking at various JavaScript libraries, I came across SJCL, which has a lovely demo page here: http://bitwiseshiftleft.github.com/sjcl/demo/
From this, it seems that what a client needs to know (besides the password used) in order to decrypt the ciphertext is:
The initialization vector
Any salt used on the password
The key size
Authentication strength (I'm not totally sure what this is)
Is it relatively safe to keep all of this data with the ciphertext? Keep in mind that this is an open source codebase, and there is no way I can reasonably hide these variables unless I ask the user to remember them (yeah, right).
Any advice appreciated.
Initialization vectors and salts are called such, and not keys, precisely because they need not be kept secret. It is safe, and customary, to encode such data along with the encrypted/hashed element.
What an IV or salt needs is to be used only once with a given key or password. For some algorithms (e.g. CBC encryption) there may be some additional requirements, fulfilled by chosing the IV randomly, with uniform probability and a cryptographically strong random number generator. However, confidentiality is not a needed property for an IV or salt.
Symmetric encryption is rarely enough to provide security; by itself, encryption protects against passive attacks, where the attacker observes but does not interfere. To protect against active attacks, you also need some kind of authentication. SJCL uses CCM or OCB2 encryption modes which combine encryption and authentication, so that's fine. The "authentication strength" is the length (in bits) of a field dedicated to authentication within the encrypted text; a strength of "64 bits" means that an attacker trying to alter a message has a maximum probability of 2-64 to succeed in doing so without being detected by the authentication mechanism (and he cannot know whether he has succeeded without trying, i.e. having the altered message sent to someone who knows the key/password). That's enough for most purposes. A larger authentication strength implies a larger ciphertext, by (roughly) the same amount.
I have not looked at the implementation, but from the documentation it seems that the SJCL authors know their trade, and did things properly. I recommend using it.
Remember the usual caveats of passwords and Javascript:
Javascript is code which runs on the client side but is downloaded from the server. This requires that the download be integrity-protected in some way; otherwise, an attacker could inject some of his own code, for instance a simple patch which also logs a copy of the password entered by the user somewhere. In practice, this means that the SJCL code should be served across a SSL/TLS session (i.e. HTTPS).
Users are human beings and human beings are bad at choosing passwords. It is a limitation of the human brain. Moreover, computers keep getting more and more powerful while human brains keep getting more or less unchanged. This makes passwords increasingly weak towards dictionary attacks, i.e. exhaustive searches on passwords (the attacker tries to guess the user's password by trying "probable" passwords). A ciphertext produced by SJCL can be used in an offline dictionary attack: the attacker can "try" passwords on his own computers, without having to check them against your server, and he is limited only by his own computing abilities. SJCL includes some features to make offline dictionary attacks more difficult:
SJCL uses a salt, which prevents cost sharing (usually known as "precomputed tables", in particular "rainbow tables" which are a special kind of precomputed tables). At least the attacker will have to pay the full price of dictionary search for each attacked password.
SJCL uses the salt repeatedly, by hashing it with the password over and over in order to produce the key. This is what SJCL calls the "password strengthening factor". This makes the password-to-key transformation more expensive for the client, but also for the attacker, which is the point. Making the key transformation 1000 times longer means that the user will have to wait, maybe, half a second; but it also multiplies by 1000 the cost for the attacker.