> Honestly, whipping up a security scheme the way I have done it is a > couple of days' work (including login and management screens). I'm not > sure why people seem to be averse to it. You just work up your screens, I suppose it does depend on the use case. If you're building a system for internal use, and you know your users, and the data is potentially exposed by other avenues (as is the case with all the internal-use systems I've built), that's one thing. But if the site is public, indexed by Google, and gets even a small amount of traffic -- or even if it's an unpublicized site but it's on a dedicated IP that belongs to a prominent hosting company -- it's going to be hammered daily by script-kiddies and PC-based malware. If it gets a lot of traffic it's probably going to be targeted by sophisticated attackers. At that point I'd personally be much more at ease knowing that session-management, authentication, password-storage, etc. were handled by a system that several more-experienced programmers have worked on, which has gotten a good deal of production use in diverse contexts, not to mention possible analysis by professional security experts. Security is complicated and it's very easy to get wrong. What hashing algorithm do you use (in the general sense of "you") to store your passwords? Do you salt your passwords; if so, do you salt them correctly? How do you handle password-resets? What's your PRNG, and is it random enough, and how do you know? I just reviewed the code for a scratch-built system that seemed to have reasonably-intelligent authentication and password management -- but /completely left out/ access-control! All I had to do was enter a different uid in the URL of the "my account" page and I could get to anyone's account, even the admin's, as long as I was authenticated. Dumb mistake? Sure. Easy to make? Probably more so than one would like to think. Ben -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
