Hi all,
I'd like to bring up security between application programming and the database. With all the Hackers out there and it being more high profile, I'm starting to ponder writing more secure software. I believe I've been somewhat successful, but like always, what people don't know is usually what gets them. So let's discuss security. I want to start off my discussing what I've done, and I hope people can poke holes into my logic and tell me where I fail. Other people are welcome to join in and post their questions and hopefully get an answer as well.
1) With my latest software, it's being designed entirely on Windows and Active Directory logins/passwords are my authentication. I've designed the DB to not have any service accounts, and to use ONLY windows authentication.
2) Fields in the database that are sensative, such as SSN#, and Credit card information are encrypted using AES-256 encryption using MS SQL's certificates and symmetrical keys.
3) All access to the SQL database is done through only stored procedures, for reading and writing.
4) I've created a user table that stores the active directory GUID for the user, and the current MSSQL SPID (if logged in), again, in AES-256 encryption.
5) In order to get into the system, the application passes the active directory GUID into a "login" stored procedure. It then opens the security certificate/key, decrypts the field from the user table in the stored procedure, and then matches it up to the passed in GUID. If the user is not logged in already, the current SPID is encrypted and written into the user table.
6) All reading stored procedures take the active directory GUID, and SPID and then decrypt the user table to verify those calling the stored procedure is actually an active directory user, and that the spid was indeed from the person who logged in. If it doesn't map up, then the stored procedure returns nothing.
That's about it.
Problems I see:
1) If someone gets into the domain by hacking an admin account, and steals the database file, all sensative fields are encrypted. They can load it onto their system, but they'd have to setup a domain on their end and mimic the active directory GUID, have the database master key, then call the Login script, before they can query. Too easy to bust? I know there are scripts out there that can transmit master keys between servers, so I'm sure they can if they know enough, get the data somehow, if they managed to get into the domain. But what if they don't have my database symmetrical key, I'm not sure if the master key and symmetrical key will work unless they know the symmetrical key. Most of the scripts I've seen to get the master key assume you h ave the symmetrical key handy. Something like that.
Is there any other issues people see in the logic?
I'd like to bring up security between application programming and the database. With all the Hackers out there and it being more high profile, I'm starting to ponder writing more secure software. I believe I've been somewhat successful, but like always, what people don't know is usually what gets them. So let's discuss security. I want to start off my discussing what I've done, and I hope people can poke holes into my logic and tell me where I fail. Other people are welcome to join in and post their questions and hopefully get an answer as well.
1) With my latest software, it's being designed entirely on Windows and Active Directory logins/passwords are my authentication. I've designed the DB to not have any service accounts, and to use ONLY windows authentication.
2) Fields in the database that are sensative, such as SSN#, and Credit card information are encrypted using AES-256 encryption using MS SQL's certificates and symmetrical keys.
3) All access to the SQL database is done through only stored procedures, for reading and writing.
4) I've created a user table that stores the active directory GUID for the user, and the current MSSQL SPID (if logged in), again, in AES-256 encryption.
5) In order to get into the system, the application passes the active directory GUID into a "login" stored procedure. It then opens the security certificate/key, decrypts the field from the user table in the stored procedure, and then matches it up to the passed in GUID. If the user is not logged in already, the current SPID is encrypted and written into the user table.
6) All reading stored procedures take the active directory GUID, and SPID and then decrypt the user table to verify those calling the stored procedure is actually an active directory user, and that the spid was indeed from the person who logged in. If it doesn't map up, then the stored procedure returns nothing.
That's about it.
Problems I see:
1) If someone gets into the domain by hacking an admin account, and steals the database file, all sensative fields are encrypted. They can load it onto their system, but they'd have to setup a domain on their end and mimic the active directory GUID, have the database master key, then call the Login script, before they can query. Too easy to bust? I know there are scripts out there that can transmit master keys between servers, so I'm sure they can if they know enough, get the data somehow, if they managed to get into the domain. But what if they don't have my database symmetrical key, I'm not sure if the master key and symmetrical key will work unless they know the symmetrical key. Most of the scripts I've seen to get the master key assume you h ave the symmetrical key handy. Something like that.
Is there any other issues people see in the logic?
