I have this school project of mine that involves an app and a website that use t
ID: 657802 • Letter: I
Question
I have this school project of mine that involves an app and a website that use the same database. The app serves as an administration tool for the website. Since it's made in C# and it's not as secure as PHP, I decided to have the app interact with the database through the website:
On the website, there's a php file used to establish a link between the app and the database. This is the algorithm i set up to have it as secure as possible:
1. User inputs a password in the app, it sends it to the php file as a parameter (/get.php?pwd=1234)
2. The website sends a token (call it T0) to the app
3. The next time the app wants send a query to the website, it sends the md5 of T0 (call it T1), the website on its side calculates the md5 of T0 and compares it T1
4. The next query has to be sent using the md5 of T1 (T2) and the website will compare it with md5 of T1
What's good about this method is that in case of a man-in-the-middle (assuming he doesn't know we use the md5 of the token), reading either the password or T0, it won't serve any purpose.
As an additional security measure, every used token is saved in a separate database containing exact location of the user, ip and the operation done with it.
Since I'm no security expert, I wanted to know how hard it is to infiltrate this system. Thank you
Explanation / Answer
First, may I ask why you think the app is not as secure as the website? Generally speaking, from a security perspective, one of the worse things you can possibly do is to involve PHP, which has more security pitfalls then, well, probably all of the other common technologies combined.
Additionally:
1. if you're any sensitive traffic from the app to the website, it needs to be over HTTPS.
2. Do not submit passwords as querystring parameters. This practically ensures that they'll be logged in plaintext, even if transported over HTTPS. Then need to be POSTed as form values instead.
3. Hashing the token doesn't do much for you. If you're submitting it over HTTPS, a MitM can't get it. If you aren't, an attacker can generate an MD5 just as easily as you can.
4. Saving the used tokens is a good idea, from an anti-replay perspective. You don't really need to save the ancillary information..It'll take up storage and probably won't give you much in the way of useful data.
5. However, saving the tokens can be a problem if you aren't using HTTPS, because an attacker who knows your scheme (and you should assume that an attacker will know your scheme) can pre-calculate the next token and hijack the session going forward, not only impersonating the real application, but also DoS'ing the real application out, because when it sends the next tokens, they'll already be in the used tokens table.
There are likely other issues here, but these are the first few that I've seen.
The bottom line is that I think this scheme needs a re-think, and a trip back to the drawing board.