php-general Digest 14 Feb 2009 14:16:10 -0000 Issue 5958
Topics (messages 288246 through 288256):
Lightweight Picasa API v3
288246 by: John Corry
Re: Happy 1234567890 day!
288247 by: German Geek
for the security minded web developer - secure way to login?
288248 by: German Geek
288253 by: Michael A. Peters
288254 by: Per Jessen
288255 by: Dotan Cohen
288256 by: Michael A. Peters
Re: [Fwd] How to make a secured login form
288249 by: German Geek
Re: Execute EXE with variables
288250 by: German Geek
288252 by: Ashley Sheridan
Re: list all constitute group of array ?
288251 by: German Geek
Administrivia:
To subscribe to the digest, e-mail:
php-general-digest-subscr...@lists.php.net
To unsubscribe from the digest, e-mail:
php-general-digest-unsubscr...@lists.php.net
To post to the list, e-mail:
php-gene...@lists.php.net
----------------------------------------------------------------------
--- Begin Message ---
Anyone using Cameron Hinkle's Picasa API?
I'm having a bitch of a time trying to get the AuthSub methods working
and would love to trade ideas if anyone is familiar.
thanks,
John Corry
email: jco...@gmail.com
--- End Message ---
--- Begin Message ---
It's not the 1234567890th day! Its the 12345Gmail - [PHP] Happy 1234567890
day! - th.he...@gmail.com <?shva=1#label/PHP/11f70b391d7613f7>67890 second
since beginning of 1970:
2009-02-14 12:31:30
is the result of
$a = 1234567890;// * 60*60*24;
die(date("Y-m-d H:i:s", $a));
Anyway happy 1234567890 second to all of you, although i'm sure i'm late lol
(i'm a German who is always late).
Regards,
Tim-Hinnerk Heuer
http://www.ihostnz.com
Mike Ditka - "If God had wanted man to play soccer, he wouldn't have given
us arms."
2009/2/14 alexus <ale...@gmail.com>
> wooooooooot!!!
>
> On Fri, Feb 13, 2009 at 6:38 PM, Eric Butera <eric.but...@gmail.com>
> wrote:
> > On Fri, Feb 13, 2009 at 5:13 PM, Gary Maddock-Greene
> > <g...@maddock-greene.co.uk> wrote:
> >> Note quite there yet here but yes Happy 1234567890 day to you too
> >>
> >> --
> >> - Gary Maddock-Greene
> >> "Luke Slater" <l...@blog-thing.com> wrote in message
> >> news:200902131812.43295.l...@blog-thing.com...
> >>
> >> --
> >> PHP General Mailing List (http://www.php.net/)
> >> To unsubscribe, visit: http://www.php.net/unsub.php
> >>
> >>
> >
> > woot!
> >
> > --
> > http://www.voom.me | EFnet: #voom
> >
> > --
> > PHP General Mailing List (http://www.php.net/)
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
> >
>
>
>
> --
> http://alexus.org/
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--- End Message ---
--- Begin Message ---
Hi All,
A few months ago it came to my mind, that it might be possible to make
non-https session (reasonably) secure by at least not letting people login
that shouldn't because they might have sniffed the password from a user.
Please let me know if you can find a loop hole in this process. I think it
would be interesting for anybody on this list (or anybody really) who has a
bit of knowlege and appreciation about security:
Assumptions:
The session variables are stored on the web server and not transferred to
the client at all.
The client has Javascript enabled.
We have a secure hash function, say sha1.
We can generate truly random numbers/strings with PHP which cannot be
guessed call it salt.
A session cannot be stolen.
... add more if needed. :-)
So, we could on the server generate a random salt value and send that to the
client along with the login form.
On the client, when the user submits the form, we take the entered password
value (with Javascript), hash it with our sha1 function, concatenate it with
the salt and compute the hash value of the password together with the salt
(again). All this in Javascript or whatever runs on the client.
We then send this hash value, call it h(h(p) + s) (hash(hash(password) +
salt)), to the server. Its useless for the sniffer, because the same value
will never be sent twice, unless of course the user (password) and the salt
are the same (or there is a collision, but we assumed its a secure hash
function).
We could make sure that a user doesn't get sent the same salt twice by
storing them in the database when used and checking against them when it is
generated.
On the server we could do the same process with the stored hash of the
password (assuming the hash of the password is stored), otherwise it becomes
necessary to also send the actual salt of the password along with the login
form and this would become even a little more complex.
So, if h(p) is stored, we would simply compute h(h(p) + s) where s is the
salt that was sent and stored in a session variable.
Assuming we don't use a salt to store the password hash, this seems quite
secure to me, don't you think? I mean, of course someone can still steel the
session but it becomes a lot harder to figure out the password by sniffing.
What do you think?
If everybody agrees this is worth implementing, i might give it a go and
make a library.
Sorry this is not directly PHP related, but since i like this list, i
thought i would share it with you.
Regards,
Tim
Tim-Hinnerk Heuer
http://www.ihostnz.com
Joan Rivers - "Never floss with a stranger."
--- End Message ---
--- Begin Message ---
German Geek wrote:
> What do you think?
I think just use a flippin' ssl server and be done with it.
When I go to a website that requires me to let them execute JavaScript I
rarely go back.
You can use SSL for the login and only the login - I know that it means
either using a self signed cert or paying big bucks, for anything with
e-commerce you want to pay big bucks for a cert, there is no other
option. For anything not e-commerce, using a self signed cert seems a
lot more secure to me than having the browser grab some salt off your
server, use javascript to encrypt the pass, and then sending it back.
Public / Private key is the way to go, and self signed cert still gives
you that, the only issue is the user get's a warning the first time they
connect to the server - and have to manually accept your cert.
You may make the password a little more difficult to sniff by sending
some salt to the client and using js to make a password hash, but the
bottom line is a user has no reason to trust a login is secure if you
don't use SSL and every reason not to trust that it is secure, so use
SSL if you want to provide secure login and don't cripple your site by
having the audacity to require users to allow you to execute code on
their machine in order to use your website. It will drive some users away.
Not exactly what you asked, but it is my opinion.
--- End Message ---
--- Begin Message ---
Michael A. Peters wrote:
> German Geek wrote:
>
> > What do you think?
>
> I think just use a flippin' ssl server and be done with it.
>
That was my thought too.
> You can use SSL for the login and only the login - I know that it
> means either using a self signed cert or paying big bucks, for
> anything with e-commerce you want to pay big bucks for a cert, there
> is no other option.
http://www.cacert.org/
/Per
--
Per Jessen, Zürich (0.2°C)
--- End Message ---
--- Begin Message ---
> I think just use a flippin' ssl server and be done with it.
>
++$i
> When I go to a website that requires me to let them execute JavaScript I
> rarely go back.
>
Many people do this, I hope that the OP realizes this.
> You can use SSL for the login and only the login - I know that it means
> either using a self signed cert or paying big bucks, for anything with
> e-commerce you want to pay big bucks for a cert, there is no other option.
> For anything not e-commerce, using a self signed cert seems a lot more
> secure to me than having the browser grab some salt off your server, use
> javascript to encrypt the pass, and then sending it back.
>
Have you seen the fit Firefox 3 makes for self-signed certs? So far as
the end user is concerned, the site is inaccesible.
--
Dotan Cohen
http://what-is-what.com
http://gibberish.co.il
א-ב-ג-ד-ה-ו-ז-ח-ט-י-ך-כ-ל-ם-מ-ן-נ-ס-ע-ף-פ-ץ-צ-ק-ר-ש-ת
ا-ب-ت-ث-ج-ح-خ-د-ذ-ر-ز-س-ش-ص-ض-ط-ظ-ع-غ-ف-ق-ك-ل-م-ن-ه-و-ي
А-Б-В-Г-Д-Е-Ё-Ж-З-И-Й-К-Л-М-Н-О-П-Р-С-Т-У-Ф-Х-Ц-Ч-Ш-Щ-Ъ-Ы-Ь-Э-Ю-Я
а-б-в-г-д-е-ё-ж-з-и-й-к-л-м-н-о-п-р-с-т-у-ф-х-ц-ч-ш-щ-ъ-ы-ь-э-ю-я
ä-ö-ü-ß-Ä-Ö-Ü
--- End Message ---
--- Begin Message ---
Dotan Cohen wrote:
Have you seen the fit Firefox 3 makes for self-signed certs? So far as
the end user is concerned, the site is inaccesible.
Yes I have.
That's why on my site I have an instruction page - and a demonstration
of how Opera does it, which is just as secure and less of a PITA, and a
suggestion that users go ahead and try Opera - something I never did
before FF messed up the self signed SSL process.
The FF3 really bugged me -
1) The purpose of SSL is to provide public/private key encryption.
2) The purpose of signing is so that they know you are really you on
future visits.
3) The purpose of certificate authorities is so that they know you are
you on the first visit.
Many web sites benefit from the first two without needing the complexity
of the third, a concept FireFox seems to have lost.
I don't need the paperwork hassle etc. for the few sites I run - I just
need a way for a user to authenticate so I can give 'em a session
cookie, no sensitive data is ever collected. Ah well.
--- End Message ---
--- Begin Message ---
Have a look at my post called "for the security minded web developer -
secure way to login?". It seems like a similar idea with less overhead.
Regards,
Tim
Tim-Hinnerk Heuer
http://www.ihostnz.com
Joan Rivers - "Never floss with a stranger."
2009/2/14 Virgilio Quilario <virgilio.quila...@gmail.com>
> > I have secured the login form for my CMS with a challenge-response thing
> > that encrypts both username and password with the
> > (login-attempts-counted) challenge (and; here's my problem: a system
> > hash) sent by the server (it would end up in your html as a hidden
> > inputs, or as part of a json transmission)..
> >
> > Since then, i've found these libs that do even longer one-way-crypto:
> > http://mediabeez.ws/downloads/sha256.js-php.zip
> > The principles i'm about to explain stay the same.
> >
> > *but i'd really like to know if my crypto can be improved*
> >
> > So instead of the browser getting just a text-field for username and
> > password, you also send the "challenge" (and "system_hash") value.
> > That's a 100-character random string (include special characters!), then
> > sha256-ed (for prettiness mostly i think).
> >
> > I really wonder if i can do without the systemhash..
> >
> > ------------------------------------ HTML
> --------------------------------
> > <form id="myForm">
> > <input type="hidden" id="system_hash" name="system_hash"
> > value="[SHA256 SORTA-MASTER-KEY__DUNNO-WHAT-TO-DO-WITH-THIS]"/>
> > <input type="hidden" id="challenge" name="challenge"
> > value="[SHA256RANDOMSTRINGFROMPHP]"/>
> > <table>
> > <tr><td>Login</td><td> </td><td><input id='login'
> > name='login'/></td></tr>
> > <tr><td>Password</td><td> </td><td><input id='pass'
> > name='pass'/></td></tr>
> > </table>
> > </form>
> >
> >
> > ------------------------------------ JS
> ------------------------------------
> >
> > $('#myform').submit (function() {
> > var s = ($'system_hash')[0];
> > var c = ($'challenge')[0];
> > var l = $('#login')[0];
> > var p = $('#pass')[0];
> >
> > l.value = sha256 (sha256 (l.value + s.value) + c.value);
> > p.value = sha256 (sha256 (p.value + s.value) + c.value);
> >
> > //Here, submit the form using ajax routines in plain text,
> > as both the login name and
> > //password are now one-way-encrypted.
> > //
> > //on the PHP end, authentication is done against a mysql
> > table "users".
> > //
> > //in this table i have 3 relevant fields:
> > //user_login_name (for administrative and display purposes)
> > //user_login_name_hash (==sha256 (user_login_name +
> > system_hash))
> > //user_password_hash (== passwords aint stored unencrypted
> > in my cms, to prevent admin corruption and pw-theft by third parties;
> > the password is encrypted by the browser in the "new-password-form" with
> > the system hash before it's ever sent to the server. server Never knows
> > about the cleartext password, ever.)
> > //
> > //when a login-attempt is evaluated, all the records in
> > "users" table have to be traversed (which i admit can get slow on larger
> > userbases... help!?! :)
> > //for each user in the users table, the loginhash and
> > password hash are calculated;
> > // $uh = sha256 ($users->rec["user_login_name_hash"] .
> > $challenge);
> > // $pwh = sha256 ($users->rec["user_password_hash"] .
> > $challenge);
> > //and then,
> > // if they match the hash strings that were sent (both of
> > them),
> > // if the number of login-attempts isn't exceeded,
> > // if the IP is still the same (as the one who first
> > requested the html login form with new challenge value)
> > //then, maybe, i'll let 'm log in :)
> > });
> >
> >
> >
> >
> > phicarre wrote:
> >>
> >> How to secure this jquery+php+ajax login procedure ?
> >>
> >> $('#myform').submit( function()
> >> {
> >> $(this).ajaxSubmit( {
> >> type:'POST', url:'login.php',
> >> success: function(msg)
> >> {
> >> **** login ok : how to call the welcome.php ***
> >> },
> >> error: function(request,iderror)
> >> {
> >> alert(iderror + " " + request);
> >> }
> >> });
> >> return false;
> >> })
> >>
> >>
> >> <form id="myForm" action="" >
> >>
> >> Name : <input type='text' name='login' size='15' />
> >> <div>Password : <input type='password' name='passe' size='15' /
> >>
> >>>
> >>> </div>
> >>>
> >>
> >> <input type="submit" value="login" class="submit" />
> >>
> >> </form>
> >>
> >> Login.php check the parameters and reply by echo "ok" or echo "ko"
> >>
> >> Logically if the answer is ok we must call a welcome.php module BUT,
> >> if someone read the client code, he will see the name of the module
> >> and can hack the server.
> >> May I wrong ? how to secure this code ?
> >>
>
> i think you should drop the IP address out of the equation because
> when you're behind a firewall with rotating outgoing IP addresses, you
> will never get authenticated.
>
> also, traversing users table is a slow operation as you pointed out.
>
> i guess you should look into two way encryption or use ssl which is
> better and easier to implement.
>
> virgil
> http://www.jampmark.com
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--- End Message ---
--- Begin Message ---
Hi,
I've had a lot of problems with shell_exec too. Mostly it was permissions or
environment variables not being set. i dont know if there is a way to set
environment variables in the php.ini but if not you can set them with
shell_exec as well, at least on unix it works. You can simply concatenate
the commands necessary with a colon (;) inbetween. Maybe you can have
multiple shell_exec commands and it stays in the same env. Not sure about
this though. Please someone enlighten us on this...
Hope some of this helped.
Regards,
Tim
Tim-Hinnerk Heuer
http://www.ihostnz.com
Jay London - "My father would take me to the playground, and put me on mood
swings."
2009/2/14 Dan Shirah <mrsqua...@gmail.com>
> >
> > Use the system() command, and enclose both your command and its
> > parameters in a pair of single quotes, as:
> >
> > system('mycmd -a alfa -b bravo');
> >
> > Paul
> > --
> > Paul M. Foster
> >
>
> Using both exec() and system() I am getting the error: Unable to fork
>
--- End Message ---
--- Begin Message ---
On Sun, 2009-02-15 at 00:16 +1300, German Geek wrote:
> Hi,
>
> I've had a lot of problems with shell_exec too. Mostly it was permissions or
> environment variables not being set. i dont know if there is a way to set
> environment variables in the php.ini but if not you can set them with
> shell_exec as well, at least on unix it works. You can simply concatenate
> the commands necessary with a colon (;) inbetween. Maybe you can have
> multiple shell_exec commands and it stays in the same env. Not sure about
> this though. Please someone enlighten us on this...
>
> Hope some of this helped.
>
> Regards,
> Tim
>
> Tim-Hinnerk Heuer
>
> http://www.ihostnz.com
> Jay London - "My father would take me to the playground, and put me on mood
> swings."
>
> 2009/2/14 Dan Shirah <mrsqua...@gmail.com>
>
> > >
> > > Use the system() command, and enclose both your command and its
> > > parameters in a pair of single quotes, as:
> > >
> > > system('mycmd -a alfa -b bravo');
> > >
> > > Paul
> > > --
> > > Paul M. Foster
> > >
> >
> > Using both exec() and system() I am getting the error: Unable to fork
> >
I use the exec() function regularly and have no troubles passing more
than one argument to it. Admittedly, I've not tried this on a Windows
system, just a Linux one, and I was using exec() to call a Bash script,
which should behave like an exe I guess.
Ash
www.ashleysheridan.co.uk
--- End Message ---
--- Begin Message ---
Do you want exactly that list or simply all the possible combinations?
If you want all possible combinations, search for a permute or permutation
function in php...
Does sound like homework lol. :-)
Regards,
Tim
Tim-Hinnerk Heuer
http://www.ihostnz.com
Alanis Morissette - "We'll love you just the way you are if you're
perfect."
2009/2/14 LKSunny <a...@pc86.com>
> <?
> $a = array("a", "b", "c", "d");
>
> /*
> how to list:
> abcd
> abc
> ab
> ac
> ad
> bcd
> bc
> bd
> cd
> a
> b
> c
> d
>
> who have idea ? thank you very much !!
> */
> ?>
>
>
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--- End Message ---
