2

I'm currently making some research on the WSSE protocol to secure my api.

I've understood the basis and it is clear in my head.

However I face to a problem.

Let's say I want to generate a ONE-time Digest, I've to concatenate the timestamp, the nonce and the secret password.

However, on the server side, I don't have the clear password stored in database, so I'm unable to check for the digest.

Switching to clear password is not an option.

I can't either provide to the client-side the algorithm used to hash password, because they use salt, and the salt is not available to the client.

The only solution I can think about is to don't hash the Digest, just concatenate the data and base64 them.

That way I'll be able to encode the user password to check for its validity.

As password is transmited in plain text it may not be secure, but what if I force HTTPS to authenticate?

Will it be safe?

AstroCB
  • 12,337
  • 20
  • 57
  • 73
Trent
  • 5,785
  • 6
  • 32
  • 43
  • This may not be the right platform for asking security related questions. U should find an appropriate RG forum and post your questions there ! – Jay D Sep 25 '12 at 17:58
  • Tag [tag:hacking] and [tag:cryptography] should really not be placed together when you are designing a secure system :) – Maarten Bodewes Sep 25 '12 at 21:47

1 Answers1

1

As password is transmited in plain text it may not be secure, but what if I force HTTPS to authenticate?

Will it be safe?

Yes, and within normal limits, it is the only way to get it secured.

Just send the full password, but send it over a well secured TLS connection. You can use a secure key derivation function such as brypt or PBKDF2 and input the stored random salt (one per user) and password to retrieve the "hash", which can then be checked to the one stored in the database.

Note that you don't need to send a time stamp from the client. It is of course a good idea to log & limit the number of authentication attempts though. You cannot use a time stamp as input to a hash, the outcome would be different each time the time stamp changes.

Community
  • 1
  • 1
Maarten Bodewes
  • 90,524
  • 13
  • 150
  • 263
  • Can you tell me more about the "secure key derivation"? One thing is I don't want to tie my clients to know and use my own algorithm, imagine my encryption algorithm is compromised my clients won't be able to use it anymore (mostly because the key has been compromised). Another thing is, if I send password in clear, I can't protect against replay attack that's right? (then the nonce and the timestamp are useless) – Trent Sep 26 '12 at 10:06
  • If you use TLS, then you are already protected against replay attacks (by eavesdroppers on the connection). If you let the clients send the plain password then you don't tie your clients to anything. If you don't use TLS then your options are pretty limited, you cannot easily prevent replay attacks (or the leaking of the password ) unless your clients implement a proprietary protocol to prevent this from happening. – Maarten Bodewes Sep 26 '12 at 13:10
  • ok thanks for the clarification, HTTPS will be required to use the API. By the way, I'm then wondering if WSSE is still needed or if I should use HTTP Basic which provides similar functionnality. – Trent Sep 26 '12 at 13:12
  • You don't particularly need it for the security if you use password based. It's more the question if you want it to have full WSDL/SOAP compliance. In that case I would recommend sticking to WSSE. The other advantage is that you can also enable XML digsig in case you need security on the message layer (as compared to transport layer security which can be provided by TLS). – Maarten Bodewes Sep 26 '12 at 13:17