|
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? |
||||
|
|
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. |
|||||
|
|
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.) |
|||
|
|
|
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. |
|||||
|
