Home/ Questions/Q 1066025
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-16T19:57:15+00:00

I’m creating an application similar to phpmyadmin (database management UI). The user needs to

  • 0

I’m creating an application similar to phpmyadmin (database management UI). The user needs to authenticate himself against the database and the application needs to store the credentials somehow. SSL is not an option for all installs.

  • Idea 1: User sends credentials, application stores username and encrypts password using predefined blowfish secret key (config.ini.php) – This is what phpMyAdmin does.
  • Idea 2: Login form creates random blowfish secret (javascript), user sends login credentials, application encrypts user/password and stores them server-side in the session, secret key is stored into cookie and sent for every request.

Idea 1: Problem if server security is breached. (Key is in config, session data in /tmp)
Idea 2: Problem with man-in-the-middle attack. (Key + credentials are sent)

Any other suggestions? Criticism?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    The problems you stated are not solvable in the absolute sense. No server is 100% secure and every “man-in-the-middle” attack can be taken a step further.

    I suggest being more specific in defining server security requirements. Otherwise every solution will appear lacking because in absolute terms they always are. For example, use session_save_path() and put the session data somewhere else if “/tmp” worries you.

    When it comes to thwarting “man-in-the-middle” attacks, then the uber-approach would be to use a one time pad, pre-shared offline. That is what security agencies do – all other options leave your application more or less dependent on the benevolence of devices between your server and the useragent. So you need to decide about your level of tolerance.

    One reasonably safe authentication method is zero knowledge proof. It requires your application only to know the public key of the user. No passwords, no secrets. The point is that when a user wants to log in, your application should respond with a random message encrypted with the public key of that user. If the other side sends back the correct random message, then it indicates the possession of a matching private key. Hence the user is authenticated. To prevent eavesdropping, make the useragent encrypt the correct answer with the public key of the application before sending the answer back. However, implementing the necessary functionality and a decent GUI for all this will not be a trivial task.

    • 0