Home/ Questions/Q 8559181
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-11T15:58:53+00:00

I am aware that you might be thinking " Do not store user’s credentials,

  • 0

I am aware that you might be thinking "Do not store user’s credentials, hash them with salt+pepper you idiot!", but please read on.

I’m working on a project that is going to ask the user about the credentials (login/password) for its database. Those credentials will be tried against the database, and if the connexion is successful, I will "keep" them for doing some work on the database as asked by the user (create a table, change a row, do a SELECT, etc).

That means, every time the user will do something, I will reconnect to the database before doing his request => I can’t hash the credentials because they will be useless for the subsequent requests. It’s like phpMyAdmin, if you like.

So I came up with various possibilities, but each of them has flaws. I’m looking for suggestions to determine which one would be better.

  1. Just use a Session cookie with login/password in clear. But allow only the use over HTTPS : This on is the most simple way to implement. The only drawback I see is if there is a XSS on the client side, the credentials can be retrieved.
  2. The same session cookie, but with encrypted login/password using AES. It’s what it is used by PhpMyAdmin I believe. I can go further by only allowing HTTPS too.
  3. Store the credential in clear in a local session storage (session.db in sqlite), and use a Token for the client that will be retrieve using the given token + browser details. Drawback : If an attacker access the session.db file, he will be able to read the sessions that haven’t been removed from the file. I don’t think encrypting them will be useful, since if he can access the session.db, he can certainly also access the SECRET_KEY used to encrypt them.

What do you think? What would you do?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    I recommend against using 1. or 2., for the following reasons:

    • The credentials are useless for the client
    • Sending he credentials over the wire on every request (in whaever form) is not a good idea

    So what stays, is a variation on Version 3., store it in the session. This has one important property: If your session storage is not secure, this means, your server is not secure. Game over.

    To protect against an attack on session.db nonetheless, you could have a hardcoded key base in your app. This key base is salted with the session token and then hashed, the result is used as a key to en- and decrypt the client credentials. This way, an attacker would need to compromise the session.db AND your app (to get the key base). If he is able to do that, nothing will help you.

    • 0