3

I'm looking at an application where admins can "invite" users by email and invited users. Invited users then are sent a unique URL and are inserted into a MySQL database with status pending and an activation token.

However, the application has a bug currently, where the DB was set up with the password field NOT NULL, and without default value, which makes INSERTs fail.

If I modify my table structure and set a default value for the password (using some arbitrary encrypted value), admins can add new users and these users are prompted to set a password prior to first login.

My question is - is there a security risk here that I should be aware of?

9
  • 2
    You might be better off asking this on Stack Overflow or Information Security.
    – mustaccio
    Jun 18 '15 at 1:28
  • ah ok, I actually thought it'll get 'off-topic'd' there..., but I may move it over if that's the concensus
    – datafunk
    Jun 18 '15 at 1:34
  • I wonder if you could set a value that no password could encrypt to? I'm no encryption expert. I agree with @mustaccio's suggestion: ask over on security.stackexchange.com Jun 18 '15 at 8:29
  • 5
    I'm voting to close this question as off-topic because it would receive a far more informed response on security.stackexchange.com Jun 18 '15 at 8:30
  • 1
    I appreciate your comments RE on/off topic too, I was debating it where to post it. For SO, it wouldn't qualify without code examples and I was struggling to boil down the relevant code to less than 3-4 files' parts. I would argue that point 3 or 4 of on-topic (dba.stackexchange.com/help/on-topic) qualifies the question here and I made my best effort to summarise the issue as succinctly as possible. On the other hand I wasn't aware of security.SE community - so thanks for that tip.
    – datafunk
    Jun 18 '15 at 22:48
0

I see only 2 options to get it to work :

  1. Application inserts value for password field
  2. Table has NULL or default value for password field

If the column allows NULL, that should be enough, right? If you want it to have a value, having the application insert it, across the network, is probably riskier, than setting a default value in the table.

Setting the same default value for all users may also pose a slight risk (someone gets a hold of the hash and tries to reverse-engineer). If you want to avoid that too, you can use a BEFORE trigger to set a computed default value based on username+timestamp as salt for the encrypted password field.

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