Subj : Re: How to implement password protection? To : comp.programming From : mwojcik Date : Sat Aug 27 2005 04:07 pm In article , Markus Becker writes: > Michael Wojcik schrieb: > > > Preventing an attacker from modifying the stored hash, as defined by > > your threat model, is left as an exercise for the reader. (Hint: The > > easiest solutions use OS facilities designed for this purpose.) > > But using OS-facilities is > not an option, since the 'user' does not want to create operating- > system-level users, but rather 'my own software' users. What I meant was: you want your software to be able to update the stored hash values (wherever they happen to be stored), but you don't want normal users to be able to update them manually (say, by editing a file). Usually the OS provides some mechanism for achieving this - though it may not always be a convenient one. The typical desktop OSes do it by restricting which user accounts can edit files containing security-sensitive information, then providing a way that authorized software can acquire that permission. On Unix, for example, the set-user-ID and set-group-ID bits in the file permission mask (for the program file) are the classic way to achieve this. When an ordinary user (who does not have the required permission) runs a program with the set-user-ID bit set, that process is granted new user credentials (which do have the required permission) by the OS. On Windows, the secure file is often managed by a system service, which generally interacts with user applications through some form of IPC. So your software has its own notion of user accounts, but you use the OS's notion of user accounts to restrict access to your user database. Some OSes have other ways to achieve this that aren't built on the user-account mechanism, but they all boil down to crossing a security boundary within your application: outside the application users can't change the secure file, but within the application, in ways tightly restricted by the application, they can. For some applications this isn't an issue; with some distributed application designs, for example, users have no access whatsoever to the system that maintains the application data, including the secure file, except through the application. -- Michael Wojcik michael.wojcik@microfocus.com Even though there may be some misguided critics of what we're trying to do, I think we're on the wrong path. -- Reagan .