There's this web app which has a SQLServer database, and the connection string it uses to access the database is not stored in any configuration file. Rather, the designers decided it would be a good idea, to write an algorithm to generate the password from the customer's license key.

Is this a common technique? Is it secure?

  • If the license key is treated as a password by the customer, which I assume will be the case, I'd say that's fine. You wouldn't want anyone having your license key anyway. – Henning Klevjer Feb 11 '13 at 19:25

The inability to change the key is the primary problem here. If it were ever to get compromised, it would be impossible for the customer to change the admin password of the database. I'd say that is a pretty big negative security implication.

  • 1
    In addition, if you ever lose your license key (in case of a reinstall or whatever) your customer now has two problems - they're relying on your record keeping for the key and relying on that for access to their data. If you ever lose a backup and have to issue a customer a new key... – Bob Watson Feb 12 '13 at 8:02

If the connection string can be generated from the license key, then I suppose that each customer will have his own license key, resulting in a distinct per-customer connection string... so you are basically giving to each customer an account on the SQLServer database, and his license key is the "password" for this account. This may or may not be a good idea, depending on the particulars of your Web app.

As a generic comment, this means that you are mixing authentication with authorization, which is not a very good idea. The license key is authentication: it is used by the client to demonstrate its identity to the server. Authorization is about deciding what a given, duly authenticated client will be allowed to do. In Active Directory terminology, the difference between authentication and authorization is the difference between verifying the password of a user, and making the user account member of the "Domain Admins" group. Authentication and authorization are distinct things which are best kept apart. In your license-key-to-connection-string proposal, you are using the license key for both, which can be restrictive.

(This distinction is often made painfully acute when dealing with PKI: all people who begin with PKI try at some point to manage access rights with certificates, and then suffering begins.)

  • Fantastic Answer: (+1). – Lex Feb 12 '13 at 9:22

This is a horrible idea for at least two reasons.

As already mentioned by AJ Henderson, the license key cannot be changed, at least not without a time-consuming exchange with the application author. So if the database password is ever compromised, the attacker can have a field day. A disgruntled ex-admin will retain database access.

A license key isn't likely to be treated as confidential inside an organization. It's the sort of thing that's normally written into in-house setup guides. It's also likely to find its way into asset lists by the accounting department.


Secure until one posts publicly that they are doing so.

  • 1
    If it is only secure by being obscure, it is not secure to begin with. – AJ Henderson Feb 12 '13 at 19:49

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.