Subj : Re: How to implement password protection? To : comp.programming From : mwojcik Date : Fri Aug 19 2005 11:26 pm In article , Markus Becker writes: > > how can implement some sort of password-protection > in one of my programs? If you want to do it securely, far and away the best option is to use existing code that has been vetted by experts, and use it correctly. Rolling your own code for security features is a poor idea unless you're an expert, and the effort required to become an expert is non-trivial. That said, some of the functions that might be considered part of "password protection" are not particularly difficult to implement, and if your threat model is generous then it can probably be satisfied relatively easily. It all depends on what your security requirements are. > I 'have heard of' (and know how to > use) MD5-hashes etc. But how is the general 'way to go' if I > want to implement several (i.e. two, 'user' and 'admin') levels > of functionality in a program? I suppose "two" is equal to "several" for sufficiently small values of "several". As a specification, this is rather incomplete. What's your threat model? Are you trying to defend against attackers who can find literal strings in a data file, for example? If not, you can store the password in the clear. Are you trying to defend against attackers who can modify your object code? If so, good luck satisfying *that* requirement. > - How can I savely store passwords without someone being able > to easily decode them (MD5-hash?)? You don't; you store a verifier, which is some value you can use to verify that an entered password (or passphrase - and supporting passphrases rather than just passwords is a good idea) matches the correct one. A cryptographic hash is certainly one way to do that: when the password is set, store the hash of the password; when it's entered, compute the hash and compare it to the stored one. 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.) There are other possibilities, some of which have advantages for circumstances that are not covered by the problem description you provided. For example, SPEKE-derived protocols like SRP and PAK-RY use zero-knowledge proofs as their verifiers, which is very advanta- geous for a distributed system, because a malicious server does not gain any knowledge of the client's authenticator. > - How do I implement some sort of group-membership that cannot > be manipulated easily? This is too large a topic for a Usenet thread, I think, though with some refinement might be suitable for a forum like SEC-PROG (a mailing list hosted by SecurityFocus). Any solution will be platform-specific (unless you're working to a rather strange threat model). > Programming language and operating systems do not matter (ideally > it would be Delphi and Windows), I'm just looking for some algorithm > to solve the problem. It's not an algorithmic problem. It's a security problem, and algorithms are the smallest (and most tractable) part of security. I'd suggest you choose one of these three approaches: 1. Start with a general computer security text like the O'Reilly _Computer Security Basics_. When you understand general computer security, move on to texts that describe security modelling (threat models, attack trees, etc) in more detail. When you have a solid model, investigate resources that discuss the factors that appear in your model. Create and implement a design that addresses your model. 2. Create a more detailed list of your requirements (this may require some research), then look for existing software - free or commercial - that addresses them. Use it. If you can't find any, hire a security professional. 3. Begin by looking at open-source packages that implement the features you think you want. Investigate what they do; research how they've succeeded or (more importantly) failed, using resources like BUGTRAQ. Adopt their code and/or roll your own. This way is perhaps the most perilous of the three - but you haven't described your actual requirements, so perhaps that's OK. (There's a genre of trivial security solutions to trivial problems, eg what is sometimes called "kid-sister cryptography"; sometimes even the weakest mechanism is good enough.) If you could provide more details about your requirements perhaps we could do a better job of guessing which route is right for you. Whom are you defending against? What capabilities do they have? -- Michael Wojcik michael.wojcik@microfocus.com Viewers are bugs for famous brands. -- unknown subtitler, Jackie Chan's _Thunderbolt_ .