The technique presented today makes full use of database server abilities to create a password reset system that is highly resistant to forgery, interception, and evil-admin meddling.
If you for a second honestly believe that this design will stop admins from being able to tamper with the process, you should be fired on sight.
If you are going to design a secure process, I'd say you should focus more on security outside your system, and worry less about keeping admins out. If you're an admin, you have full access, or the ability to give yourself the full access needed to tamper with this system.
not so fast. There are companies whose data is very sensitive. Financial, highly sensitive law firm documents, etc. And a large of percentage of data thefts is from inside jobs.
Not everybody is doing only web 2.0, where the data secrecy is not a big deal.
This may be useful in the database domain, but I don't think it applied to most web contexts.
Most web applications don't bother with database security - it muddles the logic and prevents things like pooling, scale, etc
For more traditional web apps - typically you have two sources accessing the database - the Web Application and the Administrators. Both of which have access to nearly everything anyway.
This might stop some malicious code from accessing the database improperly - but the fact is, if someone can manipulate the code you've already lost anyway (they could simply just capture the passwords at entry for example).
5 comments
[ 3.0 ms ] story [ 22.8 ms ] threadIf you for a second honestly believe that this design will stop admins from being able to tamper with the process, you should be fired on sight.
If you are going to design a secure process, I'd say you should focus more on security outside your system, and worry less about keeping admins out. If you're an admin, you have full access, or the ability to give yourself the full access needed to tamper with this system.
Not everybody is doing only web 2.0, where the data secrecy is not a big deal.
Most web applications don't bother with database security - it muddles the logic and prevents things like pooling, scale, etc
For more traditional web apps - typically you have two sources accessing the database - the Web Application and the Administrators. Both of which have access to nearly everything anyway.
This might stop some malicious code from accessing the database improperly - but the fact is, if someone can manipulate the code you've already lost anyway (they could simply just capture the passwords at entry for example).
He's sending the hash by email! And then working so hard at securing the wrong part of the process - with SSL of course, when email is not encrypted.