Secure custom API

Question

I create desktop client for one e-shop and this client will use some functions using e-shop's API, like:

GetOrders
UpdateOrder
SetOrder
etc...

I'm creating custom authentication for that client, but I don't know is it is secure against attacks.

All communication with client-server is done via HTTPS.

It works like this:

At the first request client have to provide username and password to server. So client will hash that password what user inputs and then client will send request to server with username and hashed password.
Server compares hashed password with hashed password in DB for that username, if it equal then server generates token (like api key) with limited life time and this token will send back to client.
Client will use this token in future requests.
At every successful token request server will renew token lifetime.

Requests should look like this:

POST /orders/get HTTP/1.1
Host: example.com
token=123456789&orderid=10

Is there any security recommendation if I should use POST requests or GET requests? Isn't POST more secure then GET? For example POST stores data in body of the HTTP request, but GET it stores in URL.

The use of a token is the established technique of session cookie. But your authentication looks wrong: possible duplicate of [https security - should password be hashed server-side or client-side?](https://security.stackexchange.com/questions/8596/https-security-should-password-be-hashed-server-side-or-client-side). And as for POST vs GET see [Is there a difference between GET and POST for web application security?](https://security.stackexchange.com/questions/30754/is-there-a-difference-between-get-and-post-for-web-application-security). — Steffen Ullrich, Sep 02 '18 at 12:15
@SteffenUllrich So how can I make authentication stronger? As I read it makes no sense to hash or send raw password. — tomsk, Sep 02 '18 at 12:21
In order to make the authentication stronger you need to find out what the weakness of the current way is. The weakness of your current idea is that the server needs to store a password-equivalent. This weakness is gone if you do server-side hashing instead. This is a problem is the transport of the plain password is not protected but you've addressed this with HTTPS already. But of course, a password by itself can be a weakness, since it is often badly chosen. Client certificates provide a better security but might be a hassle to use. So, find out what security you actually need. — Steffen Ullrich, Sep 02 '18 at 12:53
@SteffenUllrich So I understand, so it is strong if I use server side hashing right? So this communication is secure as far as someone doesn't broke SSL certificate right? I wonder how strong HTTPS really is. And what about man in middle attack? — tomsk, Sep 02 '18 at 13:26
*"I wonder how strong HTTPS really is. And what about man in middle attack?"*- MITM is only possible if HTTPS is not strong enough, either by design or by the actual implementation. Design of TLS (the encryption layer of HTTPS) is seen as solid and that's why it is widely used. One can of course mess up the actual implementation or configuration, for example by not properly validating certificates or by trusting CA one should better not trust. But at the end one can probably mess up even the best design by not understand what one is doing. — Steffen Ullrich, Sep 02 '18 at 14:17
@SteffenUllrich Oh okey so let's say that SSL is rock solid if not messed with configuration (I use CA Let's Encrypt). I just wonder what is point of that token, if I can send username with password to every requests if it is encrypted with SSL. — tomsk, Sep 02 '18 at 14:40
This is what Basic Authentication does. For a discussion of Basic Authentication vs. Token see [Why use an authentication token instead of the username/password per request](https://security.stackexchange.com/questions/63435) and [advantages of http basic authentication over token-based (e.g. oauth2)?](https://security.stackexchange.com/questions/68897). — Steffen Ullrich, Sep 02 '18 at 14:48
@SteffenUllrich Thank you so it is better for performance and for not storing username/password, and I saw that it is better to hash token on server side too. — tomsk, Sep 02 '18 at 15:06

score 1 · Answer 1 · answered Sep 02 '18 at 12:14

Generally it depends what you want to do with the data. There are many differences between POST and GET. If you want to transmit data to your Server i prefer POST. It´s a bit more secure then GET because it doesn´t send the information with the URL and no data is stored. If you are using a shared PC it is possible that another user is looking if URL´s are stored. Maybe one guy submited his password or other details, they will be stored on the PC and another one can find it in the history.

Get is nice to use if you want to display a message to the User. As an example: One guy tries to log in, but he missspelled his Name, so access is not granted. The webserver can now answer that way -> serverurl.com/login?error=1

If error is set to one you can display the errormessage. Below you can find more differences between POST and GET.

Secure custom API

1 Answers1