About Wsse validation--a way to authenticate users

Everyone usually validates the user approach:
1. Basic Authentication mode: After the user name and password are BASE64 encoded, placed in the HTTP header, sent to the server.
2. Form verification mode: Do not handle anything, directly to the server.
3. There are other certificate validation, summary validation, etc. that are not covered in this article.

Because it is plaintext, passwords are easily intercepted, resulting in the loss of passwords. Today and the boss to discuss the model of restful, think of the issue of certification, because rest advocates stateless, our boss mentioned the Wsse problem, so I search for a bit.

The problem with password transmission is usually solved with HTTPS, but this is perfect, but there are some limitations. In some cases can not be resolved with HTTPS, such as multiple applications using a separate IP address to access, because the server certificate information and domain name must match, so one application uses HTTPS, and the other is not used. There is also a way to use digest validation, of course, can solve this problem, but need to configure the appropriate functional modules on the server. If the server is not controllable (such as temporarily borrowing someone else's server), there is no way to do so.

The Wsse verification mode can solve the above problems. No additional configuration is required on the server. The process is as follows:
1. Start with two messages: User name and password.
2. Create a random nonce (do not know what should be translated, anyway, it is a random string that can only be used once), the generation algorithm is strong enough to let people guess what the next generation.
3. Create a "generate timestamp" and convert it to W3DTF format
4. Create a password summary:
Passworddigest = Base64 \ (SHA1 (Nonce + creationtimestamp + Password))

To illustrate:
1. The user sends a request:
HTTP Code

2. post/atom.cgi http/1.1
4. Host:bob.example.com
6. Content-type:application/atom+xml
10. <?xml version="1.0" encoding="Utf-8"?>
12. <entry xmlns="http://purl.org/atom/ns#" >
14. <title>my Entry title</title>
16. <created>2003-12-15t14:43:07z</created>
18. <content type= "application/xhtml+xml" xml:lang="en" >
20. <div xmlns="http://www.w3.org/1999/xhtml" >
22. <p>hello, <em>weblog</em> world!</p>
24. <p>this is my third post <strong>ever</strong>!</p>
26. </div>
28. </content>
30. </entry>

2. Because there is no authentication information, the server responds with 401来:
HTTP Code

1. http/1.1 401 Unauthorized
2. Www-authenticate:wsse realm="foo", profile="UsernameToken"

Note:There is also the article that the server generates a nonce, and then in the next step attached to the request, a piece to participate in the summary generation. This server nonce itself does not seem to have any use, but because the client nonce does not generate rules and length limits (even if the server does not save the previously used, can not determine whether it is the same every time), and build a server The nonce participates in the generating summary can guarantee the change of the summary, is each time inconsistent. Because this nonce is temporarily generated, once effective, in the middle of being intercepted also does not matter. At the time of validation, the server must save the nonce to the end of the validation, and then clean it up as soon as it is digest verified. However, by adding the server nonce limit, it is inevitable that the client accessing the service will access the server two times to truly access the service, but not directly attach the identity information, directly access the service. It feels like this is the standard digest validation almost, it becomes the "request-response" mode.

3. The user enters a user name and password and generates a digest to be sent to the server in usertoken form:
HTTP Code

2. post/atom.cgi http/1.1
4. Host:bob.example.com
6. Content-type:application/atom+xml
8. Authorization:wsse profile="UsernameToken"
10. X-wsse:usernametoken username="Bob", passworddigest="qur/ewlav4xlf9zqyw4pdmfv9oy=", nonce=" d36e316282959a9ed4c89851497a717f ", created=" 2003-12-15t14:43:07z "
14. <?xml version="1.0" encoding="Utf-8"?>
16. <entry xmlns="http://purl.org/atom/ns#" >
18. <title>my Entry title</title>
20. <created>2003-12-15t14:43:07z</created>
22. <content type= "application/xhtml+xml" xml:lang="en" >
24. <div xmlns="http://www.w3.org/1999/xhtml" >
26. <p>hello, <em>weblog</em> world!</p>
28. <p>this is my third post <strong>ever</strong>!</p>
30. </div>
32. </content>
34. </entry>

4. The server generates a digest from the timestamp and nonce and the password saved by the server, which allows the user to access the resource if authenticated.

Such a process, I think can solve some problems, but there are some questions:
1. Because customers want to generate abstracts and client nonce, the client must have the ability to generate them, or the browser supports such a protocol.
Now that the client is powerful, JavaScript can generate the digest. Specific program reference: http://pajhome.org.uk/crypt/md5/, so far there seems to be no browser to support this protocol.

2. Because only the digest is sent, there is no real password to resolve the middle attack concerns.
This is good, this effect is going to be.

3. Because the nonce is used only once, the next time randomly generated another, because this is generated on the client, if the generation of violent guessing password situation what to do?
This nonce is only used once to fail, can prevent hacker's replay attack. However, this process does not prevent brute force attacks, but there is a time stamp should be available, such as the server to determine 3 or 1, 2 seconds can not retry the login, although not completely avoided, but at least to reduce the number of attacks. In fact, the best solution is a strong password, a strong password to solve the problem is more thorough. If you cannot force a user to use a strong password, we can add a mechanism to the code that is normally used. There is also the above mentioned server nonce should also be able to some effect.

4. If the server does not save the real password, but only to save the digest, then this method will not be able to verify the legitimacy of the user?
If the server does not save the true password, it is the digest. such as LDAP generally do not save the plaintext password, the general database will not save the real plaintext password, this problem I really can not think of any way. If the server's Digest algorithm is exactly the same as the client, the client summary can be generated in the following ways:
passworddigest = Base64 \ (SHA1 (Nonce + creationtimestamp +DIGEST (Password)))。
is to generate a summary of the password, and then use the combination to generate a new digest. This will also be able to successfully verify the user's legitimacy on the server side.

I think this method can be used in conjunction with other methods, it should be very effective. At least one more layer of protection.

The idea of this article comes mainly from: http://www.xml.com/pub/a/2003/12/17/dive.html, which also refers to his test of HTTP data. Add to my own understanding.

If anything is wrong, I hope to be corrected. Finally thanks to "Atom Authentication" author Mark. But what does atom have to do with Wsse, and it's not clear that atom is just an implementation of wsse? Hope to know the brothers and sisters give some hints.

About Wsse validation--a way to authenticate users