-1

i'm trying to make another security layer above the 2FA layer for super admin panel/login

what i have in mind so far is a shared key (shared seed) to generate random guids that is created by client-server communication (c# client, asp.net core server api), the client/server communicate to get the number of the random number sequence (both have a private shared key), so they both can generate same guid that the admin can then use to login to his panel (which then he use 2FA to login)

assume that this shared key is dynamic, and no one else has access to this tool but the admin (used to generate the shared key) then would it be secure ?

(will limit the usage of this login page to one time in less than 5 mins), is that safe enough? any loop holes i can't see?

also assume that server api / client communications are secured with one time pad password that is encrypted inside the client with another one time pad, and the random generator isn't linear and isn't easy to predict (not like linear PRNG)

  • 2
    That basically sounds like TOTP, which after a 1-time setup on a device provides a commonly-used 2nd factor. Do you mean something different? – Ben Jun 1 '17 at 17:03
  • yes and no, i didn't knew about TOTP till just now, but i want to have something customized for this certain app that no one else will understand or break in case they figured it out, it's more like HOTP (just read about it) – m s lma Jun 1 '17 at 17:13
1

I don't know that this is an ideal scheme. It sounds like you're effectively trying to authenticate the machine (by use of a client app that contains/uses a pre-shared key) but if that is in fact the case, this probably isn't the way to do it.

Key management is hard. You need to protect the pre-shared key on both the server and the client in this design, or all is lost, at least as far as this particular layer of security is concerned. It would probably be easier and more secure to use an established mechanism like client certificates instead.

Additionally you say:

also assume that server api / client communications are secured with one time pad password that is encrypted inside the client with another one time pad...

I'm not sure what the actual design you have in mine for the communication channel entails, but don't build something yourself. Use TLS.

So, as a commenter pointed out, this sounds like TOTP based 2FA. Since you already have an established 2FA mechanism for the user, don't roll an additional version yourself. Use something like client certs for additional client authentication instead, and call it a day.

  • i am accepting this answer for the lack of a better one and the lack of me being able to explain what i've in mind, nevertheless i'm against well established protocols as once they break, they break everywhere, so i would rather take my chances in implementing another unique layer that the attacker may never guess/understand, but thanks anyway – m s lma Jun 1 '17 at 17:21
  • 2
    "I'm rejecting advice to use well-established methods generally agreed to be good security practices, in favor of rolling my own protocol with so little domain knowledge that I didn't even know what TOTP was." Sounds like a winning product you're working on. You ARE going to screw that up. Use a standard well-established method. – Ben Jun 2 '17 at 16:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.