Can you spot a vulnerability in my authentication protocol?

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:

1. 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.

2. 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.