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
