0
votes

How about this system. I need some comments and maybe critical security part for this.

System which I use is maybe little bit complicated but 100% custom and should be good. This is a system for custom authentication in sending request to Asp.NET WebApi

System works with sending 2 request

Everything what you need is 2 pairs of data. 1st one is public and 2nd one is secret.

Second pair of data be must be known to both sides (sender and receiver)

public: ApiKey and RequstID where ApiKey is "normal" and requstID have to be unique always;

secret: UserName and Password (both side have to know these data)

Sender: Send 1st request with 3 parameters: 1st= ApiKey, 2nd=RequstID, 3rd=Hash(ApiKey+RequestID+USerName+Pass)

Server: Read RequstID Read ApiKey and get data about users UserName and Pass for this ApiKey From the own side: Hash(ApiKey+RequestID+USerName+Pass)

Check is Hash from Sender same us from Server

If is False: BadRequest - or whatever...

if is True

Before all - Create on database on table for collect data about request. This is table with columns (e.g.): ID(autoincrement), RequstID, Token, TokenValidateDateTime

Before create new row, check is there already this RequestID and if there is return BadRequest. If there is not - make new row.

  1. RequstID is RequstID from request;
  2. Token - Generate token (e.g. Guid.NewGuid().ToString());
  3. TokenValidateDateTime= DateTime.Now.AddMinutes(2) - or some other value ...

In response for the first request send back this this Token (from item 2)

In the second request, Sender have to use AGAIN same RequstID and Token (from response before)

Server will check Combination RequstID and Token Token validation (depend on current date time);

Is everything is OK, user is validated if is not - BadRequest, or whatever

Any suggestions or comments are welcome :)

1
Im not sure if this would fit more into Information Security or Software Engineering... But why does both Side needs to know Username and Password? Isn't it enough to let your server know the username and crypted password? Storing important and valuable values like passwords client side is almost always a big security issue. - Cataklysim

1 Answers

0
votes

It sounds similar to traditional website username / password authentication which returns a session cookie.

But you're also including a api key & request id and a hash. The hash won't add to much value unless there's a shared salt, as once someone works out your hashing technique it will be vulnerable to dictionary attacks.

Also generating a Guid token isn't "cryptographically secure", it is designed to be unique but it's often based upon the system clock meaning it is predictable.

Building bespoke security mechanisms are generally unadvised; doing bespoke encryption is defiantly a "no no" (which you aren't doing as far as I'm aware). Bespoke authentication is probably less risky, but seeing as there are many frameworks already existing that have been critiqued by security experts I'd suggest researching if any of those suit first.

I'd recommend looking at asp.net core's security options: https://docs.microsoft.com/en-us/aspnet/core/security/?view=aspnetcore-2.1