3

I created a web admin panel with the following security implementation.

  1. It is located on a sub directory of the web, which will trigger a 404 Error when tried to access (just like the link is broken or doesn't exist).
  2. This (only if correct sub directory is opened) in turn sends an email to the administrator, with a url, which has a token.
  3. The token is of 2 parts, one is a random md5 of 5 random 5 digit numbers, another one is a md5(strrev(md5(IP_ADDR))). The token is saved in the database by invalidating all the other sessions.
  4. These tokens are separated by a _ sign.
  5. When admin (or anyone) tries to access the URL, first the IP token is matched whether the same IP is accessing the URL. If not, 404 page is shown.
  6. If yes, then the random token saved on database is matched against the one which was sent on mail. If this is also successful, the admin panel opens.
  7. Any invalid try will show 404 error.
  8. This token will automatically get invalidated for every 20 min, thanks to the cron job.

Provided, the email can only be opened by the administrator of the website.

What could be the flaws in this implementation? How can this be improved?

Sibidharan
  • 250
  • 1
  • 7

2 Answers2

2

There is unlikely to be a single answer to this question as each may cover different flaws. Here are some, only concerning token derivation and use of 404:

The second part of the token can be directly calculated by any adversary as they know their own IP address. It can therefore be removed without reducing security.

The use of a hash in the first part of the token does not add any security value, but increases overhead (although likely negligible, it is still pointless). The point of the one-time password is that it is difficult for an adversary to guess the randomly-generated value; hashing the value does nothing to increase the difficulty as an adversary needs to guess the 5 original numbers or the hash.

The guess-space with the former is 1e25 values as one can simply concatenate all numbers. This is equivalent to log(1e25) / log(2) = 83.05 bits; you do not magically get MD5's 128.

Do you need to increase this? My guess would be that a brute force attack would sooner DOS you, but there is little harm in using more space so go for it.

The use of 404 errors is security by obscurity which is not security.

Arran Schlosberg
  • 904
  • 1
  • 7
  • 14
  • 1
    Which *provides negligible security*. Security by obscurity is security, or it'd be called non-security by obscurity. – user253751 Apr 07 '16 at 02:14
  • 1
    Nitpick: 5 independent numbers of 5 decimal digits is 10^25 or 1e25, equal to 83.05 bits. But CSPRNGS almost always do bits and bytes not digits; '5 digits' *could* mean a non-secure and low-quality RNG like `rand()` in many C implementations which actually delivers 15 or 16 bits per call not the 16.61 of a true 5-digit-decimal number, but much more importantly is seeded with no more than 32 bits entropy and often much less. – dave_thompson_085 Apr 07 '16 at 09:35
  • Thanks @dave_thompson_085 - not a nitpick, an obvious error in my typing, carried across to Google calculator, and then back. Number of bits corrected. – Arran Schlosberg Apr 07 '16 at 13:40
1

Independent of the quality of your 5 digit random number I would like to elaborate on your claim "Provided, the email can only be opened by the administrator of the website."

We assume that the administrators email account is protected only by password. This way you combine one password (email password) with probably the password of the web admin interface. Resulting in two passwords which can be attacked in a similar manner. The attacker may think "how incovenient, I have to grab two passwords". But he is good in attacking passwords! No matter if he does it once or twice.

So you should think about adding something, where the attacker is not good at. A real 2nd factor like a hardware token or a yubikey. Maybe even a crappy Google Authenticator (assumed he is not good at getting malware to your smartphone). By the way all these are supported by open source privacyidea.

cornelinux
  • 1,993
  • 8
  • 11