RE: [PHP] Re: Securing user table with sha function

2007-02-21 Thread Tim
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:[EMAIL PROTECTED] 
> Envoyé : mercredi 21 février 2007 07:15
> À : php-general@lists.php.net
> Objet : Re: [PHP] 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"" <[EMAIL PROTECTED]> wrote in message 
> news:[EMAIL PROTECTED]
> > On Tue, February 20, 2007 4:08 am, Tim wrote:
> >>
> >>
> >>> -Message d'origine-
> >>> De : Haydar Tuna [mailto:[EMAIL PROTECTED]
> >>> Envoyé : mardi 20 février 2007 10:34
> >>> À : php-general@lists.php.net
> >>> Objet : [PHP] 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

Re: [PHP] Re: Securing user table with sha function

2007-02-20 Thread Haydar Tuna
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"" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
> On Tue, February 20, 2007 4:08 am, Tim wrote:
>>
>>
>>> -Message d'origine-
>>> De : Haydar Tuna [mailto:[EMAIL PROTECTED]
>>> Envoyé : mardi 20 février 2007 10:34
>>> À : php-general@lists.php.net
>>> Objet : [PHP] 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



RE: [PHP] Re: Securing user table with sha function

2007-02-20 Thread Richard Lynch
On Tue, February 20, 2007 4:08 am, Tim wrote:
>
>
>> -Message d'origine-
>> De : Haydar Tuna [mailto:[EMAIL PROTECTED]
>> Envoyé : mardi 20 février 2007 10:34
>> À : php-general@lists.php.net
>> Objet : [PHP] 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



Re: [PHP] Re: Securing user table with sha function

2007-02-20 Thread Richard Lynch
On Mon, February 19, 2007 5:12 am, Fergus Gibson wrote:
>> 4) if user forget his or her password, you can send email to the
>> user when
>> the user answer password protected question.
>
> Kinda impossible if the password is hashed, isn't it?  What a strange
> thought, though.  I guess all those sites with password reminder
> functions have the password stored in plain text somewhere.

Yes.

And email is inherently insecure medium, unless you have exchanged
off-line key pairs or something and the user has the skill to install
crypted email software packages.

Even the sites that generate a new random password to email to you
risk the email being inspected in transit, even if the password in the
db is not plain text anywhere at all.

You need at least 3 passwords to surf the web, really.

#1. Real password for like, online banking, where you're pretty sure
they have security "right" (well, the odds are good anyway)

#2. Second level real password for, like, personal info sites, or
"important" private data.

#3. Useless throw-away password for stupid sites you don't really care
about that require a password.

You might even want a #1a for online shopping where you would HOPE the
online store did it right, but don't want to risk the password that
unlocks your bank account, just in case they are one of the ones that
got it very very very wrong.

Something like eBay or Amazon or PayPal, if you use them frequently,
might warrant yet another good password.

Now if I could just remember which EMAIL or USERNAME I used for each
site, I'd be all set... :-(

-- 
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



Re: [PHP] Re: Securing user table with sha function

2007-02-20 Thread Satyam
- Original Message - 
From: "Tim" <[EMAIL PROTECTED]>







-Message d'origine-
De : Haydar Tuna [mailto:[EMAIL PROTECTED]
Envoyé : mardi 20 février 2007 10:34
À : php-general@lists.php.net
Objet : [PHP] 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?



One aproach I have often seen to security is making things complicated, 
assuming that it will deter intrussion.  Complicating things, though, rarely 
achieves anything useful. Being paranoid about some data you might be 
complicating your own work and that of those who will have to mantain and 
upgrade the application afterwards for very little gain.  There are good and 
proven ways to secure an application.  If you rarely see anyone going beyond 
those basic rules it is because the pay off is marginal in terms of security 
but too complicated in terms of mantainability.  Take the user name you are 
so concerned about.  Are you subscribed to eBay and get their newsletter? 
They send you their mailings with your username in clear to let you know it 
is indeed from them.  eBay runs one of the most secure open sites in the 
world, and they don't mind sending your login name in the clear, and nor do 
I so, why should you?   Just complicating things don't make a site more 
secure, it just complicates it.


Satyam

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



RE: [PHP] Re: Securing user table with sha function

2007-02-20 Thread Tim
 

> -Message d'origine-
> De : Fergus Gibson [mailto:[EMAIL PROTECTED] 
> Envoyé : lundi 19 février 2007 12:01
> À : php-general@lists.php.net
> Objet : [PHP] Re: Securing user table with sha function
> 
> Tim wrote:
> > Now moving on into other aspects of security :P I was thinking of a 
> > way to secure my login inputs the best way possible.
> [...]
> 
> Maybe I'm missing something, but why not simply inspect and 
> clean input to ensure that it's always properly escaped and 
> safe to send to your database?  It seems to me that's the 
> most sensible way to address SQL injection.

Yes i agree partially, an error in the "cleaning" algo could easily open up
to injection, their are so many "workarounds" to standard input filtering
how to catch them all?

> Hashing the data in your database has drawbacks, and anyway, 
> do you want them to see even hashed data?  I sure don't.
> 
> --
> 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



RE: [PHP] Re: Securing user table with sha function

2007-02-20 Thread Tim
 

> -Message d'origine-
> De : Haydar Tuna [mailto:[EMAIL PROTECTED] 
> Envoyé : mardi 20 février 2007 10:34
> À : php-general@lists.php.net
> Objet : [PHP] 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?


> Haydar TUNA
> Republic Of Turkey - Ministry of National Education Education 
> Technology Department Ankara / TURKEY
> Web: http://www.haydartuna.net
> 
> ""Haydar Tuna"" <[EMAIL PROTECTED]> wrote in message 
> news:[EMAIL PROTECTED]
> > Hello,
> >
> > 1) If you protect your site from SQL Injection, you must 
> replace all 
> > quote and blank character in your form data. (with string functions)
> > 2) After this step, you can  compare your password (with SHA1) and 
> > database password field (with SHA1).
> > 3) if comparing passwords are true, then you must use session 
> > variables for username
> > 4) if user forget his or her password, you can send email 
> to the user 
> > when the user answer password protected question.
> >
> >
> > --
> > Haydar TUNA
> > Republic Of Turkey - Ministry of National Education Education 
> > Technology Department Ankara / TURKEY
> > Web: http://www.haydartuna.net
> >
> > ""Tim"" <[EMAIL PROTECTED]> wrote in message 
> > news:[EMAIL PROTECTED]
> >> Hello,
> >>
> >> Now moving on into other aspects of security :P I was 
> thinking of a 
> >> way to secure my login inputs the best way possible.
> >> Seeing how many different types of injection attacks their is and 
> >> while observing different authentication systems I often 
> notice the 
> >> sha() function being used for passwords, which of course is the 
> >> minimum requirements to saving passwords but.. Why manipulate this 
> >> information in clear text wether it be email or username or pass 
> >> fields, such as when you use sessions/cookies, or any 
> other method of 
> >> passing authentication information from page to page (an 
> sha hash is 
> >> x times less "geussable" then any other human term)... AND how to 
> >> secure for injection attacks?
> >>
> >> Now this is where i thought hey, on every login page there 
> is a user 
> >> and pass input field and thus this is the only place one 
> could "peak" 
> >> into my user table, and I don't want someone injecting 
> through their 
> >> as the user table (three fields seperate from profile, username, 
> >> email, pass) is the key to entry to the site.. SO, why not just 
> >> encrypt all three fields? And store "copies" of email and username 
> >> (not pass :P) in another database unecrypted or with a salt for 
> >> further recovery..
> >>
> >> This would ensure that ANY information entered into the user and 
> >> passowrd will be run through sha() thus creating a 40 char length 
> >> hash and covering any (?) injection possiblity through a 
> forged input 
> >> in one of those fields via my "select" routine..
> >>
> >> Just wondering what other security conscious people think 
> of this "plan"
> >> even though it may slow down logins a tad but the tight 
> security in 
> >> my opinion justifies this..
> >>
> >> Does anyone see an ugly flaw in this scheme?
> >> Does it look viable?
> >>
> >> Thanks for any input,
> >>
> >> Regards,
> >>
> >> Tim
> 
> --
> 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



[PHP] Re: Securing user table with sha function

2007-02-20 Thread Haydar Tuna
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.

Haydar TUNA
Republic Of Turkey - Ministry of National Education
Education Technology Department Ankara / TURKEY
Web: http://www.haydartuna.net

""Haydar Tuna"" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
> Hello,
>
> 1) If you protect your site from SQL Injection, you must replace all quote 
> and blank character in your form data. (with string functions)
> 2) After this step, you can  compare your password (with SHA1) and 
> database password field (with SHA1).
> 3) if comparing passwords are true, then you must use session variables 
> for username
> 4) if user forget his or her password, you can send email to the user when 
> the user answer password protected question.
>
>
> -- 
> Haydar TUNA
> Republic Of Turkey - Ministry of National Education
> Education Technology Department Ankara / TURKEY
> Web: http://www.haydartuna.net
>
> ""Tim"" <[EMAIL PROTECTED]> wrote in message 
> news:[EMAIL PROTECTED]
>> Hello,
>>
>> Now moving on into other aspects of security :P I was thinking of a way 
>> to
>> secure my login inputs the best way possible.
>> Seeing how many different types of injection attacks their is and while
>> observing different authentication systems I often notice the sha() 
>> function
>> being used for passwords, which of course is the minimum requirements to
>> saving passwords but.. Why manipulate this information in clear text 
>> wether
>> it be email or username or pass fields, such as when you use
>> sessions/cookies, or any other method of passing authentication 
>> information
>> from page to page (an sha hash is x times less "geussable" then any other
>> human term)... AND how to secure for injection attacks?
>>
>> Now this is where i thought hey, on every login page there is a user and
>> pass input field and thus this is the only place one could "peak" into my
>> user table, and I don't want someone injecting through their as the user
>> table (three fields seperate from profile, username, email, pass) is the 
>> key
>> to entry to the site.. SO, why not just encrypt all three fields? And 
>> store
>> "copies" of email and username (not pass :P) in another database 
>> unecrypted
>> or with a salt for further recovery..
>>
>> This would ensure that ANY information entered into the user and passowrd
>> will be run through sha() thus creating a 40 char length hash and 
>> covering
>> any (?) injection possiblity through a forged input in one of those 
>> fields
>> via my "select" routine..
>>
>> Just wondering what other security conscious people think of this "plan"
>> even though it may slow down logins a tad but the tight security in my
>> opinion justifies this..
>>
>> Does anyone see an ugly flaw in this scheme?
>> Does it look viable?
>>
>> Thanks for any input,
>>
>> Regards,
>>
>> Tim 

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



[PHP] Re: Securing user table with sha function

2007-02-20 Thread Fergus Gibson
Tim wrote:
> Now moving on into other aspects of security :P I was thinking of a way to
> secure my login inputs the best way possible.
[...]

Maybe I'm missing something, but why not simply inspect and clean input
to ensure that it's always properly escaped and safe to send to your
database?  It seems to me that's the most sensible way to address SQL
injection.

Hashing the data in your database has drawbacks, and anyway, do you want
them to see even hashed data?  I sure don't.

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



[PHP] Re: Securing user table with sha function

2007-02-20 Thread Fergus Gibson
Haydar Tuna wrote:
> 1) If you protect your site from SQL Injection, you must replace all quote 
> and blank character in your form data. (with string functions)

A better approach is data inspection.  For example, if you know a field
should only ever contain letters, you can use ctype_alpha() to confirm
that.  Since alpha characters would never create a script injection, you
don't even need to do anything further with it.

If you need to allow dangerous characters, use an appropriate escaping
algorithm.  I work with MySQL all the time, so I use the
real_escape_string() method of the mysqli object when necessary.

The conceptual key to writing secure applications is understanding that
ALL input is tainted (i.e. potentially dangerous).  This includes the
results of database queries.  Your PHP application has no way to know
the data coming out of the database is positively safe.  Using
inspection and escaping as appropriate, you transform tainted data into
safe data.  I will often do so this way:

$mysql = array();
if (isset($_POST['firstName']) && ctype_alpha($_POST['firstName']))
$mysql['firstName'] = $_POST['firstName'];
if (isset($_POST['comments']))
// $database holds a mysqli object
$mysql['comments'] = $database->real_escape_string($_POST['comments']);

>From this point onward in my application, all operations work with the
values in the $mysql array, because I have either confirmed it as safe
or escaped it appropriately.


> 3) if comparing passwords are true, then you must use session variables for 
> username

You don't have to, but it's generally convenient to do so.  You should
be aware of session hijacking and place safeguards in the session data,
such as checking IP and/or user agent.


> 4) if user forget his or her password, you can send email to the user when 
> the user answer password protected question.

Kinda impossible if the password is hashed, isn't it?  What a strange
thought, though.  I guess all those sites with password reminder
functions have the password stored in plain text somewhere.

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



RE: [PHP] Re: Securing user table with sha function

2007-02-19 Thread Tim
 

> -Message d'origine-
> De : Haydar Tuna [mailto:[EMAIL PROTECTED] 
> Envoyé : lundi 19 février 2007 08:12
> À : php-general@lists.php.net
> Objet : [PHP] Re: Securing user table with sha function
> 
> Hello,
> 
> 1) If you protect your site from SQL Injection, you must 
> replace all quote and blank character in your form data. 
> (with string functions)
> 2) After this step, you can  compare your password (with 
> SHA1) and database password field (with SHA1).
> 3) if comparing passwords are true, then you must use session 
> variables for username
> 4) if user forget his or her password, you can send email to 
> the user when the user answer password protected question.

Yes i have read many tutorials with this "classic" method of authentication
system.
My "vision" is to tighten it even more by using only sha1() strings in my
SELECT statements for both username and password field.
Upon conversion to SHA regardless of the input you get a 40char string so no
need for classic form input filtering using my method of storing username
and pass as SHA hash's...

Ie: 
$query = 'SELECT * FROM users WHERE username=\'' . Sha1($_POST['username'])
. '\' and pass=\'' . Sha1($_POST['pass']) . '\''; 

Well was just an idea, i'll try it, doesn't seem to interest many people,
that's ok keep using the classic method ;P

Regards,

Tim
> --
> Haydar TUNA
> Republic Of Turkey - Ministry of National Education Education 
> Technology Department Ankara / TURKEY
> Web: http://www.haydartuna.net
> 
> ""Tim"" <[EMAIL PROTECTED]> wrote in message 
> news:[EMAIL PROTECTED]
> > Hello,
> >
> > Now moving on into other aspects of security :P I was thinking of a 
> > way to secure my login inputs the best way possible.
> > Seeing how many different types of injection attacks their is and 
> > while observing different authentication systems I often notice the 
> > sha() function being used for passwords, which of course is the 
> > minimum requirements to saving passwords but.. Why manipulate this 
> > information in clear text wether it be email or username or pass 
> > fields, such as when you use sessions/cookies, or any other 
> method of 
> > passing authentication information from page to page (an 
> sha hash is x 
> > times less "geussable" then any other human term)... AND 
> how to secure 
> > for injection attacks?
> >
> > Now this is where i thought hey, on every login page there 
> is a user 
> > and pass input field and thus this is the only place one 
> could "peak" 
> > into my user table, and I don't want someone injecting 
> through their 
> > as the user table (three fields seperate from profile, username, 
> > email, pass) is the key to entry to the site.. SO, why not just 
> > encrypt all three fields? And store "copies" of email and username 
> > (not pass :P) in another database unecrypted or with a salt for 
> > further recovery..
> >
> > This would ensure that ANY information entered into the user and 
> > passowrd will be run through sha() thus creating a 40 char 
> length hash 
> > and covering any (?) injection possiblity through a forged input in 
> > one of those fields via my "select" routine..
> >
> > Just wondering what other security conscious people think 
> of this "plan"
> > even though it may slow down logins a tad but the tight 
> security in my 
> > opinion justifies this..
> >
> > Does anyone see an ugly flaw in this scheme?
> > Does it look viable?
> >
> > Thanks for any input,
> >
> > Regards,
> >
> > Tim
> 
> --
> 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



[PHP] Re: Securing user table with sha function

2007-02-18 Thread Haydar Tuna
Hello,

1) If you protect your site from SQL Injection, you must replace all quote 
and blank character in your form data. (with string functions)
2) After this step, you can  compare your password (with SHA1) and database 
password field (with SHA1).
3) if comparing passwords are true, then you must use session variables for 
username
4) if user forget his or her password, you can send email to the user when 
the user answer password protected question.


-- 
Haydar TUNA
Republic Of Turkey - Ministry of National Education
Education Technology Department Ankara / TURKEY
Web: http://www.haydartuna.net

""Tim"" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
> Hello,
>
> Now moving on into other aspects of security :P I was thinking of a way to
> secure my login inputs the best way possible.
> Seeing how many different types of injection attacks their is and while
> observing different authentication systems I often notice the sha() 
> function
> being used for passwords, which of course is the minimum requirements to
> saving passwords but.. Why manipulate this information in clear text 
> wether
> it be email or username or pass fields, such as when you use
> sessions/cookies, or any other method of passing authentication 
> information
> from page to page (an sha hash is x times less "geussable" then any other
> human term)... AND how to secure for injection attacks?
>
> Now this is where i thought hey, on every login page there is a user and
> pass input field and thus this is the only place one could "peak" into my
> user table, and I don't want someone injecting through their as the user
> table (three fields seperate from profile, username, email, pass) is the 
> key
> to entry to the site.. SO, why not just encrypt all three fields? And 
> store
> "copies" of email and username (not pass :P) in another database 
> unecrypted
> or with a salt for further recovery..
>
> This would ensure that ANY information entered into the user and passowrd
> will be run through sha() thus creating a 40 char length hash and covering
> any (?) injection possiblity through a forged input in one of those fields
> via my "select" routine..
>
> Just wondering what other security conscious people think of this "plan"
> even though it may slow down logins a tad but the tight security in my
> opinion justifies this..
>
> Does anyone see an ugly flaw in this scheme?
> Does it look viable?
>
> Thanks for any input,
>
> Regards,
>
> Tim 

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php