3

I am currently working on a RESTful webservice with Java that is used by mobile devices, namely Android and iOS, using a framework that allows me to abstract from both. I'm adding this information because it means that I am slightly limited when it comes to the use of frameworks that might help with security.

What I am currently doing is the following:

The client has the password stored in plaintext in an app-internal file. That's because I need to send the username+password with each request --> RESTful. It is transmitted via the HTTP authorization header as username:password Base64 encoded. The transmission is done via HTTPS. The server decodes username+password and computes a hash from the password which he then checks with a hash for that user in the database. I have taken the hashing algorithm and code from here and here.

My assumptions:

  • If I assume that the client itself has not been compromised, this should be secure.
  • If someone gains access to the server's database, the users should still be safe because the passwords are hashed.
  • I can transmit the passwords to the server in plaintext (Base64), because the transmission itself is secured via HTTPS.

I'm only working on this project in my spare time, which means I don't want to spend too much time on security alone and since it's just a game, hijacking an account wouldn't be that critical as well. However, I would still like to have a robust authentication mechanism.

My questions:

  • Are my assumptions correct?
  • How would it be possible to compromise my current approach?
  • What could I do to further improve security?
Improve this question

1 Answer 1

Reset to default
2

One way to attack this would be with a replay attack. If I get hold of the message I can re-send it and the server would think that I'm an authenticated user and will grant me access.

This can be solved with server sending a challenge(e.g. one-time token). The challenge needs to be included in some way together with the username and password. Important is that this challenge/token needs to random for the guy with malicious intent to not be able to guess it. An even more simpler solution could be to add the timestamp and have an interval in which the timestamp included in the reply must be within.

Improve this answer
2
  • This is actually something I didn't think about at all. I think only being able to copy and re-execute past requests is pretty limiting in terms of possible attacks, but it still is an issue. Do you have any links or more detailed explanations as to how exactly a secure challenge token might be generated and processed?
    – noone
    Feb 13, 2015 at 16:57
  • Well, like you say it's a spare time project, so generate a timestamp and then compare it against a time interval. A very important thing is to invalidate the received packets on the server side, otherwise there is the possibility for a replay attack once again. If you choose the other option you need to look into a secure (pseudo)random generator. Searching for "challenge-response authentication" might give an answer otherwise.
    – Anders Nordin
    Feb 13, 2015 at 19:10

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .