-->
Page 1 of 1

Cript/Hash sensitive data over network

PostPosted: Wed Mar 09, 2016 6:46 am
by jmaurin
Hi!
I'm creating a new device that act as a webserver and I need to send/receive username and password to authenticate commands (I'm using REST). But, since Arduino/ESP doesn't support SSL, what's the best way to protect my data against, for example, a sniffer that could grab my URL's and copy/paste modifying some values?
I know that I could hash my username/password......but this would be one time. And since 'hacker' could grab my data, they can simple copy/paste the hashed username/password and make new call's.....they simple doesn't need to know the real password, just copy/paste and send new requests. Anybody had this kind of problem?
With SSL (on Arduino web server), would be hard (not impossible) to grab these data/URL's.

Re: Cript/Hash sensitive data over network

PostPosted: Wed Mar 09, 2016 6:38 pm
by jmaurin
For who have interest in this, i think I found a possible solution. Is not ideal, but I think it's enought.

1) Client (application) call one specific URL of ESP. This especific URL doesn't need any auth and returns a code that could be anything (i'm thinking about 6 digits number). This code is stored in variable in ESP too.

2) Applications get this code and use to make a final hash using this code + user password. This will generate a single hash/code.

3) Application calls URL for services/data on ESP and send this hash as a special header. Ex: 'AuthKey: XXXX'.

4) ESP proccess URL and check if header "AuthKey" exists. If no, drop/exit function and return error. If exists, generate a local hash (using variable with 'code' + user password that's stored in EEPROM). If the hash is the same from header sent by application, authentication is done. If not, authentication is wrong.

5) On the server reply (with data or error, doesn't matter), generate a new 'code' and send back to application. So every call and return from ESP should have a different 'code' for generating hash. Will never be the same for subsequent calls, theorically.