Oops, didn't mean to offend or start a fight. Thank you all for your input, its about the same as on the web: there is no right way.. Well i'll just have to mix and match all these methods and decide which works best for me. Just for info, yes its a dedicated server, and i am hosting the same application multiple times for multiple clients. No open hosting is allowed so no worrying about unauthed php-scripts.. My application is an modulable engine somewhat like a cms but much more complicated as it is doubled with a "site generator" for maximum flexibility depeding on the client enabling our "small" company to easly adapt to any needs a client could possibly want in the way of features by modulating each one. Which makes it quite complicated as its totally database driven weather it is for the theme, the placement of blocks, the userlevel of modules, admin user levels (client admin and our own admin extension) etc.. So i'm just mainly worried about my host server going down for whatever reason as i host all my clients on it :) But with an extensive backup system in place, which i hope never have to use to restore, i am fairly "safe". I'll just have to adapt these "security" methods based on whats known to be one of the "best" ways. Once again thanks for your input, it's my call now :D Tim > -----Message d'origine----- > De : Haydar Tuna [mailto:haydartuna@xxxxxxxxxx] > Envoyé : mercredi 21 février 2007 07:15 > À : php-general@xxxxxxxxxxxxx > Objet : Re: Re: Securing user table with sha function > > Hello, > Yes you are right I have no idea what he is doing. I'm > sorry. I write a book now about PHP and I want to help people > anywhere in the world. I like helping people because I'm a > linux user. I am membership of Linux Community in Turkey. As > you know, linux users share their knowledges or experiences. > Again I'm sorry if you see me the wise guy. I only like > helping people:) > Sincercely. > > > Haydar TUNA > Republic Of Turkey - Ministry of National Education > Education Technology Department Ankara / TURKEY > Web: http://www.haydartuna.net > > ""Richard Lynch"" <ceo@xxxxxxxxx> wrote in message > news:47415.216.230.84.67.1172018796.squirrel@xxxxxxxxxxxxxxxx > > On Tue, February 20, 2007 4:08 am, Tim wrote: > >> > >> > >>> -----Message d'origine----- > >>> De : Haydar Tuna [mailto:haydartuna@xxxxxxxxxx] > >>> Envoyé : mardi 20 février 2007 10:34 > >>> À : php-general@xxxxxxxxxxxxx > >>> Objet : Re: Securing user table with sha function > >>> > >>> Hello again, > >>> if you crypt your usernames, it happened many problems. > >>> As you know, if you crypt any string to SHA1, you don't > >>> decrypt again. You cannot use username in your application. > >>> in my many application, I have crpyted password , I haven't > >>> cryrpt usernames. Becuase I used username for session > >>> authentication. for example if I want to action on the > >>> usernames or list of usernames , what can I do this? All of > >>> usernames are crypted. > >> > >> OK then what if i consider using PHP's Mcrypt extension > with a key to > >> crypt/decrypt data, this would give me the possiblity to use a > >> username > >> crypted hash in the session variable and decrypt it at any > moment with > >> the > >> proper key? > > > > MySQL also has AES_CRYPT which will do this, so you needn't restrict > > yourself to PHP. > > > > You then have the tough question of whether it's more > likely that your > > PHP source will be exposed and the key will "leak out" leaving you > > vulnerable to attack, or, perhaps, somebody on your server > will manage > > to RUN your script that authenticates them in some way that > gives them > > more access than they should, just because they can run the script > > with the key in it. > > > > On a shared server, for MOST webhosts, all the other users on that > > server can just read your PHP scripts using PHP because, > duh, PHP has > > to be able to read your PHP script so PHP can read&execute your PHP > > script. [*] > > > > On a dedicated box where you, and only you, are the only > user that has > > a valid login, it could help slow down an attack, or, perhaps, might > > open up a hole, if you code it wrong. > > > > There isn't a "right" answer because Security is not an off-the-rack > > suit. It's a custom-tailored suit to fit the application needs. > > > > Your online bank needs a lot different security than your local > > community forum. > > > > Applying bank level security measures to the local community forum > > adds user inconvenience with no real benefit. > > > > You should always consider Security in the context of the > application > > with an eye to usability and smooth process flow on the > business side, > > and not just ultimate "security" > > > > Nobody knows which is better for what you are doing, because we have > > NO IDEA what you are doing, and you can't really tell us in > a post to > > PHP-General, even one as long as this. :-) > > > > * I am completely ignoring various commercial PHP-obfuscation tools > > other than this footnote to keep others from posting about them. > > They're out there, Google for them, use them if appropriate, coo coo > > ka choo. > > > > -- > > Some people have a "gift" link here. > > Know what I want? > > I want you to buy a CD from some starving artist. > > http://cdbaby.com/browse/from/lynch > > Yeah, I get a buck. So? > > -- > PHP General Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
