On Thu, April 14, 2005 1:57 pm, [EMAIL PROTECTED] said:
> On 14 Apr 2005 Chris Shiflett wrote:
>
>> When a user enters a credit card number, there may likely be a
>> verification step before the actual purchase is made. It's better to
>> keep this number on the server (in the session data store) th
On 14 Apr 2005 Chris Shiflett wrote:
> When a user enters a credit card number, there may likely be a
> verification step before the actual purchase is made. It's better to
> keep this number on the server (in the session data store) than to
> unnecessarily expose it over the Internet again (SS
On 13 Apr 2005 Richard Lynch wrote:
> I have what I consider a MINIMUM standard level of security for any site
> that asks for a password.
>
> That would include:
> Not storing the password *ANYWHERE* in clear-text.
> Not in database.
> Not in $_SESSION
> Not in COOKIES
Agreed. I see less
Richard Lynch wrote:
There aren't a whole lot of shared servers that are running a different
pool of httpd for each user, nor using only CGI with different user ids,
nor...
I daresay that unless you are setting up a shared server yourself, rather
than renting space on one, you'll be hard-pressed to
On Mon, April 11, 2005 8:12 pm, Chris Shiflett said:
> Richard Lynch wrote:
>> On a shared server, every other PHP scripter can read your session data,
>> if they work at it a little bit.
>
> You should mention that this is assuming a default configuration. There
> are ways to avoid this.
There ar
On Tue, April 12, 2005 4:40 am, [EMAIL PROTECTED] said:
[lots and lots of stuff, mostly valid, about Security being applied in
ratio with the data being protected]
I don't have the time to answer this point by point.
So I'll stick with some generalizations.
I have what I consider a MINIMUM stand
On Tue, April 12, 2005 8:03 pm, [EMAIL PROTECTED] said:
> On 11 Apr 2005 Chris Shiflett wrote:
>
>> > > DO NOT STORE PASSWORDS ON USERS COMPUTER
>> >
>> > A couple of people have stated this but I think it is incorrect.
>>
>> Please refrain from such speculation, because it does nothing to improve
On 11 Apr 2005 Chris Shiflett wrote:
> > > DO NOT STORE PASSWORDS ON USERS COMPUTER
> >
> > A couple of people have stated this but I think it is incorrect.
>
> Please refrain from such speculation, because it does nothing to improve
> the state of security within our community. This idea of st
Richard Lynch wrote:
On Sat, April 9, 2005 11:51 am, [EMAIL PROTECTED] said:
*WHY* would you not store some kind of hash of the user ID?!
setcookie('remember_me', md5($username));
.
.
.
select username from users where md5(username) = $_SESSION['remember_me']
Is that really any harder?
It's very ha
On Apr 12, 2005 12:05 PM, Joe Wollard <[EMAIL PROTECTED]> wrote:
> See http://us2.php.net/manual/en/function.session-set-save-handler.php
> for more details on building a custom session handler.
http://destiney.com/pub/Destiney_db_sessions_0.1.0.tar.bz2
Provides simple database driven PHP sessions
> On a shared server, every other PHP scripter can read your session data,
> if they work at it a little bit.
If you're on a shared server I think a good option for you might be to
store the sessions in your database. At least then you know that as long
as long as your db server doesn't have any
On 11 Apr 2005 Richard Lynch wrote:
> > Well, just because I'm not sure it is worth the effort. What is the
> > point of storing a hash code as a proxy (in the colloquial sense of the
> > word) for an encrypted password if knowing the hash code gets you the
> > same access as knowing the password
Richard Lynch wrote:
On a shared server, every other PHP scripter can read your session data,
if they work at it a little bit.
You should mention that this is assuming a default configuration. There
are ways to avoid this.
For truly sensitive stuff like a CC#, do *NOT* put that in session data.
W
On Sat, April 9, 2005 8:39 am, Ryan A said:
> This certainly has turned out to be an interesting discussion.I
> usually
> send the info via sessions...how bad is that?
On a shared server, every other PHP scripter can read your session data,
if they work at it a little bit.
How bad is that?
O
On Sat, April 9, 2005 11:51 am, [EMAIL PROTECTED] said:
> Well, just because I'm not sure it is worth the effort. What is the
> point of storing a hash code as a proxy (in the colloquial sense of the
> word) for an encrypted password if knowing the hash code gets you the
> same access as knowing t
On Sat, April 9, 2005 1:37 pm, Skippy said:
> On Sat, 09 Apr 2005 14:51:49 -0400 [EMAIL PROTECTED] wrote:
>> A digression to a related issue (where I did take the conservative
>> approach): A system I'm working on now was originally set up with
>> password hashes in the database -- the PW itself w
On Mon, April 11, 2005 9:13 am, Chris Boget said:
>> Please refrain from such speculation, because it does nothing to improve
>> the state of security within our community. This idea of storing
>> passwords in cookies is absurd.
>
> Is the above sentiment true even if you store the password as some
Chris Boget wrote:
> This idea of storing passwords in cookies is absurd.
Is the above sentiment true even if you store the password as some sort
of hash (md5 or otherwise)?
Yes, because passwords offer long-term access. If you accept a hash of
the password for access, then that hash becomes as se
Chris Boget wrote:
Please refrain from such speculation, because it does nothing to improve
the state of security within our community. This idea of storing
passwords in cookies is absurd.
Is the above sentiment true even if you store the password as some sort
of hash (md5 or otherwise)?
It's to
> Please refrain from such speculation, because it does nothing to improve
> the state of security within our community. This idea of storing
> passwords in cookies is absurd.
Is the above sentiment true even if you store the password as some sort
of hash (md5 or otherwise)?
thnx,
Chris
--
PH
[EMAIL PROTECTED] wrote:
> DO NOT STORE PASSWORDS ON USERS COMPUTER
>
> I hope that's clear enough.
A couple of people have stated this but I think it is incorrect.
Please refrain from such speculation, because it does nothing to improve
the state of security within our community. This idea of sto
Computer Programmer wrote:
What is a better way to store password in a cookie?
This is one of the worst ideas people have, and if I'm guessing the
reasoning behind your question correctly, this will help:
http://fishbowl.pastiche.org/2004/01/19/persistent_login_cookie_best_practice
Keep in mind t
On Sat, 09 Apr 2005 14:51:49 -0400 [EMAIL PROTECTED] wrote:
> A digression to a related issue (where I did take the conservative
> approach): A system I'm working on now was originally set up with
> password hashes in the database -- the PW itself was never stored. But
> the client wanted an "
[EMAIL PROTECTED] wrote:
On 9 Apr 2005 John Nichel wrote:
While it is not absolute that you can't store passwords in a cookie, it
is an absolute that you _shouldn't_
Sorry, I don't agree. There are very few absolute rules in software
development.
This isn't a rule. It's common sense. The les
On 9 Apr 2005 Ryan A wrote:
> This certainly has turned out to be an interesting discussion.I
> usually send the info via sessions...how bad is that?
Well if you are using sessions it is worth thinking about session
security, for example:
http://shiflett.org/articles/the-truth-abou
On 9 Apr 2005 Jason Wong wrote:
> > I might, depending on
> > the needs, store a hash code as others have suggested
>
> Why not in *all* cases?
Well, just because I'm not sure it is worth the effort. What is the
point of storing a hash code as a proxy (in the colloquial sense of the
word) fo
On 4/9/2005 3:33:50 PM, [EMAIL PROTECTED] wrote:
> On 9 Apr 2005 John Nichel wrote:
>
>
>
> > While it is not absolute that you
> can't store passwords in a cookie, it
> > is an absolute that you _shouldn't_
>
>
>
> Sorry, I
> don't agree. There are very few absolute rules in software
> developme
On ÑÐÐ, 2005-04-09 at 22:56 +0800, Jason Wong wrote:
> > Sorry, I don't agree. There are very few absolute rules in software
> > development.
>
> But in this case there really is no reason *why* you need to store a
> password (encrypted or otherwise).
IMO storing the password hash (md5,sha1, w
On Saturday 09 April 2005 21:33, [EMAIL PROTECTED] wrote:
> On 9 Apr 2005 John Nichel wrote:
> > While it is not absolute that you can't store passwords in a cookie,
> > it is an absolute that you _shouldn't_
>
> Sorry, I don't agree. There are very few absolute rules in software
> development.
B
On 9 Apr 2005 John Nichel wrote:
> While it is not absolute that you can't store passwords in a cookie, it
> is an absolute that you _shouldn't_
Sorry, I don't agree. There are very few absolute rules in software
development.
For sites accessing sensitive information or that allow spending mo
[EMAIL PROTECTED] wrote:
A couple of people have stated this but I think it is incorrect. For
one thing the users themselves are very likely to store the password
there, so why shouldn't you -- with permission of course?
If the user wants to circumvent security measures by storing passwords,
t
Thanks for all of your reply. :)
Just like what trlists said, I'd like to create an auto-login at least
with a maximum of 30 days. Users will have the option to choose
whether to logout and/or prompt for their password for the next 1
hour, 4 hours, etc. just like what Yahoo! is doing.
What is the
On Saturday 09 April 2005 19:29, [EMAIL PROTECTED] wrote:
> On 9 Apr 2005 Andy Pieters wrote:
> > It doesn't matter how you encrypt it.
> >
> > DO NOT STORE PASSWORDS ON USERS COMPUTER
> >
> > I hope that's clear enough.
>
> A couple of people have stated this but I think it is incorrect. For
> on
On 9 Apr 2005 Andy Pieters wrote:
> It doesn't matter how you encrypt it.
>
> DO NOT STORE PASSWORDS ON USERS COMPUTER
>
> I hope that's clear enough.
A couple of people have stated this but I think it is incorrect. For
one thing the users themselves are very likely to store the password
the
On Saturday 09 April 2005 02:18, Computer Programmer wrote:
> What is a better way to store password in a cookie?
>
> md5()?
> base64_encode()?
> mhash()?
> mcrypt_generic()?
> crypt()?
It doesn't matter how you encrypt it.
DO NOT STORE PASSWORDS ON USERS COMPUTER
I hope that's clear enough.
Wh
Computer Programmer wrote:
What is a better way to store password in a cookie?
There is no good way to store a password in a cookie. Just don't do it.
--
By-Tor.com
...it's all about the Rush
http://www.by-tor.com
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.
On Fri, April 8, 2005 5:18 pm, Computer Programmer said:
> What is a better way to store password in a cookie?
>
> md5()?
> base64_encode()?
> mhash()?
> mcrypt_generic()?
> crypt()?
D) None of the above.
You only think you need to store a password in a Cookie.
You don't.
Use sample code from h
37 matches
Mail list logo
