Timeline for Why are triggers not often used to secure a database?
Current License: CC BY-SA 3.0
7 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Mar 17, 2017 at 13:14 | history | edited | CommunityBot |
replaced http://security.stackexchange.com/ with https://security.stackexchange.com/
|
|
| Nov 9, 2012 at 0:39 | comment | added | Clockwork-Muse | Especially since, with anything short of parameterized query, if you miss something in either validation list (black/white), triggers might not save you anyways; they generally only get the results of the operation against a table, which wouldn't help if the DB allows multiple statements per connection. Oh, and some systems don't automatically turn them back on after a restore, either, so they might not even be on... | |
| Nov 8, 2012 at 9:41 | comment | added | symcbean | It's worth noting that using (1) stored procedures is not the same thing as using parameterized queries (though the former usually implies the latter).(2) Stored procedures also provide a means of privilege seperation, e.g. allowing a user to update a single named row at a time, but not multiple rows | |
| Nov 8, 2012 at 9:00 | comment | added | user10211 | @Matrix right thanks for that. got the two confused for a moment. | |
| Nov 8, 2012 at 8:44 | comment | added | Matrix | @Terry Chia, stored procedures can be used for comparing password hashes, not triggers. | |
| Nov 8, 2012 at 4:02 | comment | added | user10211 | Never thought of using triggers to compare password hashes. Learnt something new today, +1. | |
| Nov 8, 2012 at 2:48 | history | answered | Jeff Ferland♦ | CC BY-SA 3.0 |