I am writing an android app that will communicate with a webserver.
So far, i got the communication basics and a token based authentication system.
The tokens are really long, but i am still afraid, someone could just guess them.
So i thought about something like the following. Is this a valid approach?
My Idea:
App generates RSA keypair.
Login with mail and password over ssl (provide public key to server)
Server generates unique token
Server saves token and public key
Server returns token to app
From now on, the app uses the token, but encrypts all messages with the private key.
Server receives message with token. It tries to decrypt the data with the public key, to make sure, this message is from the original login. If it couldn't decrypt, it declines the request.
Is this a valid approach? Or is this method too weak?
Well, what you want to do is a possible approach. Here some of my thoughts regarding your idea.
The chain is as strong as the weakest link. Have you thought about how you will reset the access when the user looses the device? Are credentials enough? Is access to the mailbox enough? The attacker will choose the easiest target.
Your approach looks suspiciously similar to mutual authentication with TLS. Well, you can reinvent the wheel if you like, but I would probably stick to the standard. You don't want to solve the problem of e.g. reply attacks prevention, do you?
Why not simply use 2FA with TLS channel protection? U2F for example is even stronger than having private client TLS keys lying around.
Encryption of long messages with RSA keys is slow. You usually encrypt only a symmetric key with RSA and the rest of the message with AES.
Hope this helps somehow.
Related
I am making a little script in python, in which a client has to authenticates to the server. The idea is that an attacker cannot authenticate himself by listening to the network, without knowing the password.
Despite any good practices, I am trying to make my own secure authentication (it is only for personal use).
In my current algorithm, the client and the server share :
the password that authenticates the client
an encryption key
the encryption algorithm (AES with pycrypto)
It works as follows :
The server generates a token
The server encrypts the token
The encrypted token is sent to the client
The client decrypts the token
The client encrypts the set (password + token)
The encrypted set (password + token) is sent to the server
The server decrypts (password + token)
If the received information corresponds to the shared password and the token sent by the server, then the client is successfully authenticated.
In this algorithm, the client and the server share 2 secrets : the password and the encryption key.
I am wondering if it would be secure to do like this :
The server generates a token
The server sends the token to the client (in plain text)
The client encrypts the token, and returns it to the server
If the decrypted token is correct, the client is successfully authenticated.
In this case, the server and the client share only one secret (the encryption key). From my (small) knowledge of AES, I think that an attacker should not be able to guess the key with the token and the encrypted token, nor to guess the encrypted token without owning the key.
So my questions are: do you see any flaws in my algorithms? Is the second as secure as the first?
Thanks for your help
I am not a crypto expert (shout out to https://crypto.stackexchange.com), but AES is meant to assure confidentiality, and your method does not prevent non-repudiation. In other words, I can't read the contents of the token, but I can intercept your message and send the same one to the server to "authenticate" myself, right? (https://en.wikipedia.org/wiki/Replay_attack) Additionally, someone in the middle could modify your message and potentially cause problems, since again, AES assures confidentiality, but not integrity of the message. Aside from those core issues, there are subtle mistakes you can make when implementing this that can cause issues that are very difficult for you (and me) to detect, but possible for attackers to sniff out.
Perhaps when combined with an HMAC, you can overcome these weaknesses... but I would have to encourage you to not "roll your own" crypto scheme and perhaps all you need is HTTPS to secure the communication between the two devices (and a pre-shared token/key/password to prove identity). If you do decide to continue down this route, I would also encourage you to do significant research and having a security expert review your code/implementation before using in any sort of production environment. If this is just for fun/research, that's another story.
I would like to implement authentication for a web app api using a similar technique to the AWS Signature Process. The server will render html for user web browser clients. The app will also return json for non-browser clients (iphone, android, blackberry, ipad, etc.) I am trying to write authentication code that will allow a single user to be signed (remembered) in to the app from multiple clients. Logging out from any one client should not revoke the token/cookie for all the other clients.
When a user sign up or logs in, how does a client (native mobile client or web browser especially) get the private/secret key? My understanding is the key should not be sent over a network? Can it just be sent over ssl?
For browser clients is the private key stored in a cookie or in some other form of local storage?? I.e. for generic api token authentication would the token be stored in a cookie on the browser and in a db on the phone
When the client is a browser, how does it sign a request signature with private key? i.e. generate a hash of the id + private key + request. For native mobile clients or server to server communication I believe there are libraries that can be used to generate a signed request. When the request originates from a browser how does this work?
If a user is required to be remembered on multiple clients (tablet, iphone, work computer, home laptop, etc.) would the user need to have a set of private keys/tokens for each client?
I would have used Devise with Rails but it requires you to write your own token authentication code.
I am also looking at OAuth, which questions 2 and 4 both apply to, but would really like to investigate the AWS method.
You start with a solution (HMAC) but I do not think your "problem" fits your solution :).
I'll try to answer this to the best of my knowledge.
To my understanding ,a private key would be derived of a public key that is shared. Or you could share a private key, but only if authentication is already established (in other words: you already know for sure who you are talking to) and the connection is secured (encrypted). You still will be vulnerable to man in the middle attacks though.
I'm not sure. A cookie is not secure. Steal the cookie, steal the private key. My preference would be a locally stored key(file or storage), encrypted by a password.
You would have to devise some sort of a client side library (in javascript or something like it).
Yes.
Why share keys when you could share a token, like oAuth implements. The token is generated by your application and is valid for a limited time. This way you share access, but not the means to aquire access to your application. You login with username and password (or keyfile) and you get a token that grants you access untill the token is revoked.
I'm implementing a REST web service using C# which will be hosted on Azure as a cloud service. Since it is a REST service, it is stateless and therefore no cookies or session states.
The web service can only be accessed over HTTPS (Certificate provided by StartSSL.com).
Upon a user successfully logging into the service they will get a security token. This token will provide authentication in future communications.
The token will contain a timestamp, userid and ip address of the client.
All communication will only happen over HTTPS so I'm not concerned about the token being intercepted and used in replay attacks; the token will have an expiry anyway.
Since this is a public facing service I am however concerned that someone could register with the service, login and then modifying the token that they receive to access the accounts of other users.
I'm wondering how best to secure the content of the token and also verify that it hasn't been tampered with.
I plan on doing the following to secure the token:
The client successfully logs into the service and the service does:
Generate a random value and hash it with SHA256 1000 times.
Generate a one-time session key from private key + hashed random value.
Hash the session key with SHA256 1000 times and then use it to encrypt the token
Use private key to sign the encrypted token using RSA.
Sends the encrypted token + the signature + the hashed random value to the client in an unencrypted JSON package.
When the client calls a service it sends the encrypted token and signature in an unencrypted JSON package to the service. The service will
Recreate the session key from the private key + the hashed random value
Use the private key to verify the signature
Use the hashed session key to decrypt the token
Check that the token hasn't expired
Continue with the requested operation...
I don't really know anything about encryption so I have some questions:
Is this sufficient or is it overkill?
I read that to detect tampering I should include an HMAC with the token. Since I am signing with the private key, do I still need an HMAC?
Should I be using Rijndael instead of RSA?
If Rijndael is preferred, is the generated IV required for decrypted? i.e. can i throw it away or do I need to send it will the encrypted token? e.g. Encrypted Token + HMAC + IV + hashed random value.
Since all communication happens over HTTPS the unencrypted JSON package isn't really unencrypted until it reaches the client.
Also I may want to re-implement the service in PHP later so this all needs to be doable in PHP as well.
Thanks for your help
You are really over-thinking the token. Truthfully, the best token security relies on randomness, or more accurately unpredictability. The best tokens are completely random. You are right that a concern is that a user will modify his/her token and use it to access the accounts of others. This is a common attack known as "session stealing." This attack is nearly impossible when the tokens are randomly generated and expired on the server side. Using the user's information such as IP and/or a time stamp is bad practice because it improves predictability. I did an attack in college that successfully guessed active tokens that were based on server time stamps in microseconds. The author of the application thought microseconds would change fast enough that they'd be unpredictable, but that was not the case.
You should be aware that when users are behind proxy servers, the proxy will sometimes view their SSL requests in plain text (for security reasons, many proxies will perform deep packet inspection). For this reason it is good that you expire the sessions. If you didn't your users would be vulnerable to an attack such as this, and also possible XSS and CSRF.
RSA or Rijndael should be plenty sufficient, provided a reasonable key length. Also, you should use an HMAC with the token to prevent tampering, even if you're signing it. In theory it would be redundant, since you're signing with a private key. However, HMAC is very well tested, and your implementation of the signing mechanism could be flawed. For that reason it is better to use HMAC. You'd be surprised how many "roll your own" security implementations have flaws that lead them to compromise.
You sound pretty savvy on security. Keep up the good work! We need more security conscious devs in this world.
EDIT:
It is considered safe to include timestamps/user IDs in the token as long as they are encrypted with a strong symmetric secret key (like AES, Blowfish, etc) that only the server has and as long as the token includes a tamper-proof hash with it such as HMAC, which is encrypted with the secret key along with the user ID/timestamp. The hash guarantees integrity, and the encryption guarantees confidentiality.
If you don't include the HMAC (or other hash) in the encryption, then it is possible for users to tamper with the encrypted token and have it decrypt to something valid. I did an attack on a server in which the User ID and time stamp were encrypted and used as a token without a hash. By changing one random character in the string, I was able to change my user ID from something like 58762 to 58531. While I couldn't pick the "new" user ID, I was able to access someone else's account (this was in academia, as part of a course).
An alternative to this is to use a completely random token value, and map it on the server side to the stored User ID/time stamp (which stays on the server side and is thus outside of the clients control). This takes a little more memory and processing power, but is more secure. This is a decision you'll have to make on a case by case basis.
As for reusing/deriving keys from the IV and other keys, this is usually ok, provided that the keys are only valid for a short period of time. Mathematically it is unlikely someone can break them. It is possible however. If you want to go the paranoid route (which I usually do), generate all new keys randomly.
I'm trying to implement two-factor authentication (a token you hold, a password you know).
http://en.wikipedia.org/wiki/Security_token lists many expensive solutions. I need:
Strong encryption.
The ability to programmatically reset the private key on the token (multiple times, if the token is expensive) and read the new private key.
The ability to encrypt a short string (20 characters or less). I believe this means computational power can be very low.
Something cheap. I'd like to ship these tokens to average consumers (think VISA), if possible.
I don't need:
To protect against physical attacks on the token (I assume this is beyond the skill of the average attacker).
To kill the token remotely.
To store any data on the token aside from the private key.
Time-dependent tokens (for fear they will fall out of sync).
I plan on doing the following:
User inserts the token into a PC.
User enters their password on the keyboard.
The token encrypts the password using the private key.
The application sends the result over the network.
The server decrypts the password using the token's public key. If the password matches I let the user in.
I need to make it reasonably difficult for an average programmer/hacker to read the private key off the token. What are my options? If you believe I am setting the bar too low, what do you suggest?
if the audience is consumers then it is quite possible that the computer they use is infected somehow - virus/keyboard logger...
IF that is a possibility then the whole scheme becomes risky because of using the PC keyboard...
Putting aside those concerns:
you could run your own "CA" and generate client certificates - these can be put anywhere (USB stick...) and the application could work with them for verifying the user - by just using the passphrase as password etc. - the beauty of this is: you get for example the ability to revoke certificates etc.
another point:
Depending on how your application communicates with the server you could use this scheme to have SSL connections... SSL standard contains the option not only of authenticating the server but also the client by means of a client certificate...
EDIT:
anything cheap could be read - smartcards would be better but they are not really cheap and the PC needs additional HW to handle them...
Secure but NOT cheap option:
if you want something secure then you need an external smartcard reader with a keyboard, so that nothing sensitive it entered via PC keyboard - but that is not cheap...
another option (cheaper but still secure):
use the mobile as second channel, they login to your app - the app contacts the server, the server generates some unique and time-limited code and sends it via SMS to their mobile and they need to enter that code to complete login process...
"The server decrypts the password using the token's public key"
That doesn't make sense. The point of a public key is that can be public without compromising the security of the system. Perhaps what you meant is that the token contains a public key, and the server stores the private key corresponding to that token?
Security tokens are typically not used in the manner you describe. They are quite commonly used as single sign on (SSO) devices. The token generates a pseudo-random number that is time-dependent. In most cases, the number generated changes every 30 or so seconds. The server is configured with the random seed of the token, so it can generate the same number to verify.
Edit: As per your comment, here's my new suggestion:
Public key on token or client application
Corresponding private key on server
It doesn't matter if the public key is read since knowledge of the public key does not help in guessing the private key
If necessary, change keys at scheduled intervals
Some time ago we needed a solution for Single Sign On authentication between multiple web services. At least at that time we considered OpenID protocol too complicated and we were not convinced about the Ruby on Rails plugins for it. Therefore we designed a protocol of our own instead of implementing an OpenID provider and OpenID consumers.
I have two questions:
Was it a bad thing not to create
our own OpenID provider and setup
our OpenID consumers accept only it?
Public login or registration are not
allowed and we wanted to keep
authentication simple.
Can you spot a crucial error or a vulnerability in the following design?
If you as a commune can approve this design, I will consider extracting this code into a Ruby on Rails plugin.
Please look at the flowchart and sequence diagram.
Details:
Authentication Provider ("AP"):
Central service which holds all data
about the users.
Only one "AP" exists in this setup.
It could be possible to have multiple "AP"s, but that should not be relevant in this context.
"AP" knows each "S" beforehand.
Authentication Client (Service "S"):
There exists several internal and external web services.
Each service knows "AP" and its public key beforehand.
Actor ("A"):
The end user who authenticates
herself with AP by a username and password
May request directly any URI of "S" or "AP" prior to her login
Connections between "A", "S" and "AP" are secured by HTTPS.
Authentication logic described briefly:
These are a description for the graphical flowchart and sequence diagram which were linked at the top of this post.
1) Auth Provider "AP"
"AP" makes a server-to-server HTTP POST request to "S" to get a nonce.
"AP" generates an authentication token.
Authentication token is an XML entity which includes:
an expiration date (2 minutes from now),
the previously requested nonce (to prevent replay),
identifying name of "S" (token for Service_1 is not good for Service_2),
information about the end user.
Authentication token is encrypted with AES256 and the encryption key and initialization vector are signed by AP's private RSA key.
Resulting strings ("data", "key" and "iv") are first Base64 encoded and then URL encoded to allow them be delivered in the URL query string.
End user "A" is HTTP-redirected to service "S" (HTTPS GET request).
2) Service "S"
Receives authentication token in URL parameters from user agent.
Decrypts authentication token with AP's pre-shared public key.
Accepts one authentication token only once (token includes a nonce which is valid only once).
Checks that identifying name in authentication token corresponds to service's name.
Checks that authentication token is not expired.
Remarks:
It is not a problem if somebody else can also decrypt the authentication token, because it contains no confidential information about the user. However, it is crucial that nobody else than AP is able to generate a valid authentication token. Therefore the RSA key pair is involved.
RSA private key is used only for signing the token, because it cannot encrypt data which is longer than the actual key length. Therefore AES is used for encryption.
Since the authentication token is delivered as an HTTP GET request, it will be stored e.g. in Apache's log file. Using a disposable nonce and an expiration date should minimize the possibility of a replay attack. POST request would need an HTML page with a form which is submitted automatically by Javascript, which is why GET is used.
Service "S" generates a nonce only in a server-to-server API request. Therefore unauthenticated generation requests should not pose a DoS-vulnerability.
You're confusing authentication ("I am who I say I am") and authorization/access control ("I am allowed to access this"). You can just implement OAuth, and then query a server over HTTPS with "is this OAuth identity allowed to access me?". You don't have to worry about replay attacks, since you're using HTTPS.
"Security is hard, so I'll design my own."
Authentication token is encrypted with AES256 and the encryption key and initialization vector are signed by AP's private RSA key.
AES-256 and AES-192 have weak key schedules. But you're not using it for confidentiality; you're using it as some sort of "integrity" check. It doesn't work: Attacker gets a "signed" authentication token. Attacker recovers the key and IV. Attacker encrypts a different authentication token with the same key and IV, and uses the same "signature".
What's wrong with hashing it and signing the hash? Also note that if you're going to use custom signing, you need to be careful about padding (IIRC PKCS-whatever adds at least 11 bytes).
EDIT: And if you're using a cipher where you should be using a hash/MAC, you really shouldn't be designing a security protocol!
Here are a few quick thoughts about question 1:
Designing a working security protocol is very hard, so on general principle I would favor using an existing one.
However, I appreciate that OpenID might not have been very established at the time. Also OpenID is still relatively new and might not have all of its limitations figured out yet.
Still, you'd be using OpenID in a restricted scenario where the big issue of OpenID (involvement of multiple actors) doesn't come into play. You'd only be using the “technical core” of OpenID, which is easier to understand.
Your requirements and the overview of your protocol remind me of Kerberos. I'm also tempted to push towards LDAP + single sign on, but I don't know what concrete solutions exist for that.
A point in favor of your protocol is that you've taken the time to describe it in detail. Just that puts you above than most self-made security protocol designers!
In short I find this protocol to be over engineered in the wrong places and ultimately vulnerable to attack.
So What is the vulnerability?
End user "A" is HTTP-redirected to service "S" (HTTPS GET request).
This is likely to be a violation of OWASP A9. At no point can a user's session ID be passed over an insecure channel such as http. Even if the session id hasn't been authenticated yet, an attacker is patient he can sniff the wire looking for session id's and then periodically check if they have been authenticated and then use them to access your system.
"Complexity is the worst enemy of security."
--Bruce Schneier
Authentication token is encrypted with
AES256 and the encryption key and
initialization vector are signed by
AP's private RSA key.
First of all RSA can be used to encrypt a message, so aes is unnecessary. HTTPS on the other hand is going to be more efficient and proven to be secure. I don't understand why you have to pass an authentication token to the client, when you already have a secure server-to-server communication channel. A server could just say "Hey someone has been redirected to me with this session id, what is his state information?". Its a matter of the weakest link in the chain, and your session id should be strong enough. This would require the session id to be sent as a GET or POST request by the client when the hand off occures which could open the door to Session Fixation. You could check the ip address before and after the handoff, sometimes the ip address of the client can change legitimately but the handoff is going to be a very narrow window in which this can happen, and most importantly it is stops Session Fixation altogether.
In general you should avoid re-inventing the wheal. Especially when it comes to security problems like this which have already been solved. Kerberos is beautiful especially if you need to tie in non-http authentication. Using LDAP for session management is another possibility.
Do you really just sign AES key and then send encrypted token, RSA signature of key and then key-iv in PLAINTEXT?
It's a fail. Attacker can use this key to decrypt a token, change it in any needed way and encrypt back. Your server will never find a difference.
If you want to check token integrity, just make a hash of it and sign this hash. This is what hashes used for. No need to use encryption here.