php-general Digest 25 Aug 2010 11:32:34 -0000 Issue 6909
Topics (messages 307637 through 307650):
Re: mysqldump
307637 by: Jan G.B.
Re: How safe is a .htaccess file?
307638 by: Gary
307639 by: Brad Broerman
307640 by: Peter Lind
307641 by: Bob McConnell
307642 by: Jan G.B.
307643 by: Peter Lind
307644 by: Jan G.B.
Re: Bitwise NOT operator?
307645 by: Richard Quadling
307646 by: Andy McKenzie
307647 by: Ashley Sheridan
307648 by: Ford, Mike
307649 by: Andy McKenzie
307650 by: Richard Quadling
Administrivia:
To subscribe to the digest, e-mail:
[email protected]
To unsubscribe from the digest, e-mail:
[email protected]
To post to the list, e-mail:
[email protected]
----------------------------------------------------------------------
--- Begin Message ---
2010/8/18 Daniel P. Brown <[email protected]>:
> On Tue, Aug 17, 2010 at 15:19, tedd <[email protected]> wrote:
>>
>> Bingo -- that worked.
>>
>> It's interesting that a space is optional between -u and user, but required
>> to be absent between -p and password. Seems not symmetrical to me.
>
> The command I sent was because - as I said in the original thread
> - passing any password directly to the command line is Very Bad[tm].
> If you're passing it via exec(), though, and don't want to use an
> 'expect' shell, passing it directly to -p is at least a bit less
> dangerous. Plus, doing so will not leave anything in your
> ~/.bash_history on the server.
>
> That said, sorry for appearing inattentive, despite this being
> directed right at me. I have been out of the office more than in for
> the last couple of weeks, while working on a ton of new stuff.
> Eventually it will go back to "normal."
>
> --
> </Daniel P. Brown>
> UNADVERTISED DEDICATED SERVER SPECIALS
> SAME-DAY SETUP
> Just ask me what we're offering today!
> [email protected] || [email protected]
> http://www.parasane.net/ || http://www.pilotpig.net/
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
I recommend gzipping it on the fly and if you're using own MYSQL
functions and /or stored procedures, then I'd add --routines as
parameter to include these in your sum.
Here's my command line:
$ mysqldump -u USERNAME -p --opt --single-transaction --routines
DATABASENAME | gzip > sqldump.sql.gz
Note that you must only replace Databasename and Username in the
example.. mysqldump will ask for the passwort.
If you specify your password in the command line, then you end up
haviung it in your shell history which can make it easy for crackers.
--opt means the same as:
--add-drop-table, --add-locks, --create-options,
--quick, --extended-insert, --lock-tables, --set-charset,
and --disable-keys.
and is enabled by default.
Regards
--- End Message ---
--- Begin Message ---
Jan G.B. wrote:
> The weakness of MD5 is mainly because MD5 collisions are possible.
> That means, that different strings can have the same MD5-hash...
http://en.wikipedia.org/wiki/MD5#cite_note-1
--
Gary
PHP 5.2.12 (cli) (built: Jan 14 2010 14:54:11)
1.7.4(0.225/5/3) 2010-04-07 11:02 Cygwin
--- End Message ---
--- Begin Message ---
One thing I would do, and I have done this in many of my applications:
a) Store the username / password in a database.
b) Encrypt passwords (with a salt) with AES-256 using a key stored in a
file OUTSIDE the document path.
c) Add code to the beginning of the included file to ensure it is only
executed by approved files.
<?php
if( 0 == preg_match( "/maplerunfarm-secure\/admin.php/",
$_SERVER["SCRIPT_FILENAME"] ) )
{
exit("Error: invalid inclusion of file. Please contact your system
administrator");
}
$CONST_SECURE_KEY = "DKTAZ+2EFaSHexdE0hbKJKiO/mQeF1hd";
?>
-----Original Message-----
From: Jan G.B. [mailto:[email protected]]
Sent: Tuesday, August 24, 2010 9:09 AM
To: Andre Polykanine
Cc: Nathan Rixham; tedd; [email protected]
Subject: Re: [PHP] Re: How safe is a .htaccess file?
2010/8/19 Andre Polykanine <[email protected]>:
> Hello Nathan,
>
> Sorry, could you provide any links to read for a security noob?)
> Actually, I know that the md5 is decryptable (there are bases with
> words encrypted in md5), but I thought the SHA1 was secure...
> --
> With best regards from Ukraine,
> Andre
> ----- Original message -----
> From: Nathan Rixham <[email protected]>
> To: tedd <[email protected]>
> Date: Thursday, August 19, 2010, 12:03:12 PM
> Subject: [PHP] Re: How safe is a .htaccess file?
>
> tedd wrote:
>> Hi gang:
>>
>> The subject line says it all.
>>
>> How secure is a .htaccess file to store passwords and other sensitive
>> stuff?
>>
>> Can a .htaccess file be viewed remotely?
>
> Semi-safe,
>
> .htaccess is prevented from being served by configuration options (which
> come as default), however these can be overwritten so best to check by
> doing a GET on the resource URI.
>
> This doesn't prevent them from being exposed via other processes though,
> for instance a poorly coded 'download.php?path=/path/to/.htaccess' could
> still expose the file.
>
> Typically, its obviously better to store only a hash of a password
> rather than the pass in plain text, choosing the strongest algorithm you
> can; password security is of course relative though, a sha-512 of
> 'password1' is far from secure.
>
> A good way to approach encryption for files is to openssl_seal them
> using a public key which is only available to your application - this
> doesn't negate insecure code, but it at least ensures the raw files are
> encrypted securely enough to negate any of these worries. (just keep
> your private key safe, preferably in a pkcs12 w/a strong 64char+ pass)
>
> Best,
>
> Nathan
>
> --
> 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
>
>
Hi Nathan,
I'm not a crypto expert.. but I'll try to explain it:
The weakness of MD5 is mainly because MD5 collisions are possible.
That means, that different strings can have the same MD5-hash...
When you use "test" as a secret password, then no hashing algorythm at
can be considered as "safe". The first two passwords a cracker will
try might be "1234" and "test".. No big deal.
Databases of MD5-hashes exists. And so can exist Databases of SHA-*
hashes. To get around these databases you can just "salt" your hash..
that way the Hash of the word "test" will not be the same as the hash
in the database without *your* salt. No matter if you use MD5 or
SHA256
$ echo -ne test | md5sum
098f6bcd4621d373cade4e832627b4f6 -
$ echo -ne test-mySecretSalt | md5sum
c62fb41567c476e36ba46e5b53ae6d59 -
Only the first string will be available in a hash-database.
So you see - as long as a cracker only get's your salted hashes
WITHOUT the used salt, it's pretty safe.. as long as you don't think
about ignore collisions!
Back to topic:
- as mentioned before the biggest risk in authentication via .ht*
files is that one can try to get these files via a bug in an
application.. (e.g. ?read_file=.htaccess%00)
- that's why you don't want to use plain text-passwords in .htaccess
files. most used is the htdigest algorythm. Be sure to use a STRONG
password: long string with letter, numbers and more chars.
- if you're curious, get a copy of "John the Ripper password cracker"
and try to decode your passwords.. that's what the bad guys use once
they get your .htaccess file.
Regards
Regards
--- End Message ---
--- Begin Message ---
On 24 August 2010 15:43, Gary <[email protected]> wrote:
> Jan G.B. wrote:
>
>> The weakness of MD5 is mainly because MD5 collisions are possible.
>> That means, that different strings can have the same MD5-hash...
>
> http://en.wikipedia.org/wiki/MD5#cite_note-1
It's worth noting that that essentially does not touch upon whether or
not MD5 can be considered safe or not as a means to store password
information. The researchers have discovered ways of crafting inputs
to easily find colliding hashes - they have not discovered any easy
means to craft an input that will collide with a given hash.
Regards
Peter
--
<hype>
WWW: http://plphp.dk / http://plind.dk
LinkedIn: http://www.linkedin.com/in/plind
BeWelcome/Couchsurfing: Fake51
Twitter: http://twitter.com/kafe15
</hype>
--- End Message ---
--- Begin Message ---
From: Peter Lind
> On 24 August 2010 15:43, Gary <[email protected]> wrote:
>> Jan G.B. wrote:
>>
>>> The weakness of MD5 is mainly because MD5 collisions are possible.
>>> That means, that different strings can have the same MD5-hash...
>>
>> http://en.wikipedia.org/wiki/MD5#cite_note-1
>
> It's worth noting that that essentially does not touch upon whether or
> not MD5 can be considered safe or not as a means to store password
> information. The researchers have discovered ways of crafting inputs
> to easily find colliding hashes - they have not discovered any easy
> means to craft an input that will collide with a given hash.
That's a simple matter of brute force, which can be done once and saved
for instant use later. However, putting a salt into your algorithm
pretty much eliminates the chances of success using that attack.
Bob McConnell
--- End Message ---
--- Begin Message ---
2010/8/24 Bob McConnell <[email protected]>:
> From: Peter Lind
>
>> On 24 August 2010 15:43, Gary <[email protected]> wrote:
>>> Jan G.B. wrote:
>>>
>>>> The weakness of MD5 is mainly because MD5 collisions are possible.
>>>> That means, that different strings can have the same MD5-hash...
>>>
>>> http://en.wikipedia.org/wiki/MD5#cite_note-1
>>
>> It's worth noting that that essentially does not touch upon whether or
>> not MD5 can be considered safe or not as a means to store password
>> information. The researchers have discovered ways of crafting inputs
>> to easily find colliding hashes - they have not discovered any easy
>> means to craft an input that will collide with a given hash.
>
> That's a simple matter of brute force, which can be done once and saved
> for instant use later. However, putting a salt into your algorithm
> pretty much eliminates the chances of success using that attack.
>
> Bob McConnell
>
Thanks..
actually it's quite annoying when you post an answer which
tries to explain a subject and people just post a link as
response to one citation which somehow lacks relevance on the topic.
My intro-sentence was "I'm not a crypto expert".
Gary, do you expect me to read the full detail report of Tao Xie and
Dengguo Feng?
Can you sum it up in two or three sentences?
Regards
--- End Message ---
--- Begin Message ---
On 24 August 2010 16:25, Jan G.B. <[email protected]> wrote:
> 2010/8/24 Bob McConnell <[email protected]>:
>> From: Peter Lind
>>
>>> On 24 August 2010 15:43, Gary <[email protected]> wrote:
>>>> Jan G.B. wrote:
>>>>
>>>>> The weakness of MD5 is mainly because MD5 collisions are possible.
>>>>> That means, that different strings can have the same MD5-hash...
>>>>
>>>> http://en.wikipedia.org/wiki/MD5#cite_note-1
>>>
>>> It's worth noting that that essentially does not touch upon whether or
>>> not MD5 can be considered safe or not as a means to store password
>>> information. The researchers have discovered ways of crafting inputs
>>> to easily find colliding hashes - they have not discovered any easy
>>> means to craft an input that will collide with a given hash.
>>
>> That's a simple matter of brute force, which can be done once and saved
>> for instant use later. However, putting a salt into your algorithm
>> pretty much eliminates the chances of success using that attack.
>>
>> Bob McConnell
>>
> Thanks..
> actually it's quite annoying when you post an answer which
> tries to explain a subject and people just post a link as
> response to one citation which somehow lacks relevance on the topic.
>
The link posted was all the relevance there is. MD5 is not weak in the
sense that it is easy to find collisions when all you have is a hash
(which is what you were implying). MD5 is only weak in the sense that
it's possibly to generate two input texts such that the MD5 hashes of
both will collide.
The "other" weakness of MD5 (the more relevant one here) is that
calculating an MD5 hash is relatively fast today. Which means you can
generate rainbow tables of the most common inputs in relatively little
time. Of course, these rainbow tables are worthless against more
secure passwords and/or against salted passwords.
Regards
Peter
--
<hype>
WWW: http://plphp.dk / http://plind.dk
LinkedIn: http://www.linkedin.com/in/plind
BeWelcome/Couchsurfing: Fake51
Twitter: http://twitter.com/kafe15
</hype>
--- End Message ---
--- Begin Message ---
2010/8/24 Peter Lind <[email protected]>:
> On 24 August 2010 16:25, Jan G.B. <[email protected]> wrote:
>> 2010/8/24 Bob McConnell <[email protected]>:
>>> From: Peter Lind
>>>
>>>> On 24 August 2010 15:43, Gary <[email protected]> wrote:
>>>>> Jan G.B. wrote:
>>>>>
>>>>>> The weakness of MD5 is mainly because MD5 collisions are possible.
>>>>>> That means, that different strings can have the same MD5-hash...
>>>>>
>>>>> http://en.wikipedia.org/wiki/MD5#cite_note-1
>>>>
>>>> It's worth noting that that essentially does not touch upon whether or
>>>> not MD5 can be considered safe or not as a means to store password
>>>> information. The researchers have discovered ways of crafting inputs
>>>> to easily find colliding hashes - they have not discovered any easy
>>>> means to craft an input that will collide with a given hash.
>>>
>>> That's a simple matter of brute force, which can be done once and saved
>>> for instant use later. However, putting a salt into your algorithm
>>> pretty much eliminates the chances of success using that attack.
>>>
>>> Bob McConnell
>>>
>> Thanks..
>> actually it's quite annoying when you post an answer which
>> tries to explain a subject and people just post a link as
>> response to one citation which somehow lacks relevance on the topic.
>>
>
> The link posted was all the relevance there is. MD5 is not weak in the
> sense that it is easy to find collisions when all you have is a hash
> (which is what you were implying). MD5 is only weak in the sense that
> it's possibly to generate two input texts such that the MD5 hashes of
> both will collide.
> The "other" weakness of MD5 (the more relevant one here) is that
> calculating an MD5 hash is relatively fast today. Which means you can
> generate rainbow tables of the most common inputs in relatively little
> time. Of course, these rainbow tables are worthless against more
> secure passwords and/or against salted passwords.
>
> Regards
> Peter
>
Hi peter,
this clears it up for me. So I was quite correct with my post. :-)
Have a nice day.
Regards,
Jan
--- End Message ---
--- Begin Message ---
On 20 August 2010 17:00, Andy McKenzie <[email protected]> wrote:
> Thanks to everyone who responded. I've dealt with binary math
> before, but it never occurred to me (and doesn't seem to be anywhere
> in the document page at php.net!) that it would automatically pad the
> number I entered.
There is no padding.
php -r "echo decbin(~2), PHP_EOL, decbin(-3);"
11111111111111111111111111111101
11111111111111111111111111111101
That's 100% correct and proper. Not "padded".
The example in [1] regarding E_ALL & ~E_NOTICE is a perfect example.
Richard.
[1] http://docs.php.net/manual/en/language.operators.bitwise.php
--
Richard Quadling.
--- End Message ---
--- Begin Message ---
On Tue, Aug 24, 2010 at 11:06 AM, Richard Quadling <[email protected]> wrote:
> On 20 August 2010 17:00, Andy McKenzie <[email protected]> wrote:
>> Thanks to everyone who responded. I've dealt with binary math
>> before, but it never occurred to me (and doesn't seem to be anywhere
>> in the document page at php.net!) that it would automatically pad the
>> number I entered.
>
> There is no padding.
>
> php -r "echo decbin(~2), PHP_EOL, decbin(-3);"
> 11111111111111111111111111111101
> 11111111111111111111111111111101
>
> That's 100% correct and proper. Not "padded".
>
> The example in [1] regarding E_ALL & ~E_NOTICE is a perfect example.
>
> Richard.
>
> [1] http://docs.php.net/manual/en/language.operators.bitwise.php
> --
> Richard Quadling.
>
If I feed it "10" and it assumes "00000000000000000000000000000011",
it's padding the number with zeros.
>From your example, this would have shown me what I needed to know:
"Then taking the value of E_NOTICE...
1000
... and inverting it via ~:
11111111111111111111111111110111"
As it was, I assumed the 32-bit number was there because the author
wanted it there, not because PHP assumes those extra bits. As other
people have said, it probably would have been obvious if I'd known
more about how the system dealt with binary numbers, but coming from
my background, it wasn't at all obvious. Not a big deal, and I can
work with it now that I know what's going on, but it would have taken
me a long time to figure it out on my own, if I ever had. The tests I
was doing probably would have led me to the right answer eventually,
but Colin's original answer gave me the explanation and the solution
much faster.
-Alex
--- End Message ---
--- Begin Message ---
On Tue, 2010-08-24 at 12:24 -0400, Andy McKenzie wrote:
> On Tue, Aug 24, 2010 at 11:06 AM, Richard Quadling <[email protected]>
> wrote:
> > On 20 August 2010 17:00, Andy McKenzie <[email protected]> wrote:
> >> Thanks to everyone who responded. I've dealt with binary math
> >> before, but it never occurred to me (and doesn't seem to be anywhere
> >> in the document page at php.net!) that it would automatically pad the
> >> number I entered.
> >
> > There is no padding.
> >
> > php -r "echo decbin(~2), PHP_EOL, decbin(-3);"
> > 11111111111111111111111111111101
> > 11111111111111111111111111111101
> >
> > That's 100% correct and proper. Not "padded".
> >
> > The example in [1] regarding E_ALL & ~E_NOTICE is a perfect example.
> >
> > Richard.
> >
> > [1] http://docs.php.net/manual/en/language.operators.bitwise.php
> > --
> > Richard Quadling.
> >
>
>
> If I feed it "10" and it assumes "00000000000000000000000000000011",
> it's padding the number with zeros.
>
> From your example, this would have shown me what I needed to know:
>
> "Then taking the value of E_NOTICE...
> 1000
> ... and inverting it via ~:
> 11111111111111111111111111110111"
>
> As it was, I assumed the 32-bit number was there because the author
> wanted it there, not because PHP assumes those extra bits. As other
> people have said, it probably would have been obvious if I'd known
> more about how the system dealt with binary numbers, but coming from
> my background, it wasn't at all obvious. Not a big deal, and I can
> work with it now that I know what's going on, but it would have taken
> me a long time to figure it out on my own, if I ever had. The tests I
> was doing probably would have led me to the right answer eventually,
> but Colin's original answer gave me the explanation and the solution
> much faster.
>
> -Alex
>
It isn't padded, you just have to understand that this is how binary
numbers are dealt with by computers. The missing numbers are implied,
and when you perform binary math on them, they are used.
I would recommend reading up on binary math if you plan to use it more,
as it will reveal any more surprises like this before you encounter
them.
Thanks,
Ash
http://www.ashleysheridan.co.uk
--- End Message ---
--- Begin Message ---
> -----Original Message-----
> From: Andy McKenzie [mailto:[email protected]]
> Sent: 24 August 2010 17:24
> To: [email protected]
> Subject: Re: [PHP] Bitwise NOT operator?
> From your example, this would have shown me what I needed to know:
>
> "Then taking the value of E_NOTICE...
> 1000
> ... and inverting it via ~:
> 11111111111111111111111111110111"
>
> As it was, I assumed the 32-bit number was there because the author
> wanted it there, not because PHP assumes those extra bits.
That's not PHP. That's the underlying computer architecture, and PHP has no
choice in the matter. (Well, assuming you leave BCMath and so on out of the
equation!)
Cheers!
Mike
--
Mike Ford,
Electronic Information Developer, Libraries and Learning Innovation,
Leeds Metropolitan University, C507 City Campus,
Woodhouse Lane, LEEDS, LS1 3HE, United Kingdom
Email: [email protected]
Tel: +44 113 812 4730
To view the terms under which this email is distributed, please go to
http://disclaimer.leedsmet.ac.uk/email.htm
--- End Message ---
--- Begin Message ---
On Tue, Aug 24, 2010 at 3:55 PM, Ford, Mike <[email protected]> wrote:
>> -----Original Message-----
>> From: Andy McKenzie [mailto:[email protected]]
>> Sent: 24 August 2010 17:24
>> To: [email protected]
>> Subject: Re: [PHP] Bitwise NOT operator?
>
>
>> From your example, this would have shown me what I needed to know:
>>
>> "Then taking the value of E_NOTICE...
>> 1000
>> ... and inverting it via ~:
>> 11111111111111111111111111110111"
>>
>> As it was, I assumed the 32-bit number was there because the author
>> wanted it there, not because PHP assumes those extra bits.
>
> That's not PHP. That's the underlying computer architecture, and PHP has no
> choice in the matter. (Well, assuming you leave BCMath and so on out of the
> equation!)
>
> Cheers!
>
> Mike
True, but largely irrelevant from my point of view: I'm talking to
PHP. Even if I'd thought about it in terms of the architecture, I
would have assumed that PHP would treat a two-bit number as a two-bit
number, even if it had to do some weirdness in the background because
it's not. If I enter a decimal two, I know the computer deals with it
as binary, and now I know it probably deals with it as a 32-bit binary
number, but it doesn't show me all the extra bits: it just shows me a
two.
My point here, much as it might sound like it, isn't that PHP is wrong
for doing things the way it does. Even if I thought it is, I don't
know what I'm talking about, and I know it. What I'm saying is that
the documentation doesn't even begin to indicate to people like me
that things won't work the way we expect. Maybe that's not necessary;
certainly I've never needed it until now, and the confusion was easily
cleared up. But adding to the docs might avoid a lot of confusion for
the next guy who doesn't really know what he's doing.
-Alex
--- End Message ---
--- Begin Message ---
On 24 August 2010 21:42, Andy McKenzie <[email protected]> wrote:
> On Tue, Aug 24, 2010 at 3:55 PM, Ford, Mike <[email protected]> wrote:
>>> -----Original Message-----
>>> From: Andy McKenzie [mailto:[email protected]]
>>> Sent: 24 August 2010 17:24
>>> To: [email protected]
>>> Subject: Re: [PHP] Bitwise NOT operator?
>>
>>
>>> From your example, this would have shown me what I needed to know:
>>>
>>> "Then taking the value of E_NOTICE...
>>> 1000
>>> ... and inverting it via ~:
>>> 11111111111111111111111111110111"
>>>
>>> As it was, I assumed the 32-bit number was there because the author
>>> wanted it there, not because PHP assumes those extra bits.
>>
>> That's not PHP. That's the underlying computer architecture, and PHP has no
>> choice in the matter. (Well, assuming you leave BCMath and so on out of the
>> equation!)
>>
>> Cheers!
>>
>> Mike
>
>
> True, but largely irrelevant from my point of view: I'm talking to
> PHP. Even if I'd thought about it in terms of the architecture, I
> would have assumed that PHP would treat a two-bit number as a two-bit
> number, even if it had to do some weirdness in the background because
> it's not. If I enter a decimal two, I know the computer deals with it
> as binary, and now I know it probably deals with it as a 32-bit binary
> number, but it doesn't show me all the extra bits: it just shows me a
> two.
>
> My point here, much as it might sound like it, isn't that PHP is wrong
> for doing things the way it does. Even if I thought it is, I don't
> know what I'm talking about, and I know it. What I'm saying is that
> the documentation doesn't even begin to indicate to people like me
> that things won't work the way we expect. Maybe that's not necessary;
> certainly I've never needed it until now, and the confusion was easily
> cleared up. But adding to the docs might avoid a lot of confusion for
> the next guy who doesn't really know what he's doing.
>
> -Alex
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
I think trying to explain to someone with no knowledge of the rules is
going to be a little beyond the role of the PHP documentation. A
rudimentary understanding has to be assumed.
You are talking about decimal numbers (2, 3, 4) and then applying the
NOT operator and then expressing the result in base 10 and base 2.
Decimal numbers are column based. By worldwide and historic
convention, leading zeros are not needed. In fact, worldwide
convention has dictated that a leading 0 implies an octal number and
not a decimal one.
Binary numbers are block based. Historic/worldwide convention dictates
bits are either singular (true/false) or in blocks (bytes, words,
double-words, quad-words, etc.) OK. Nibbles/nybbles/nybles too.
You say a "two-bit number". Well, there is no such entity. As soon as
you talk in terms of bits, you are dealing in binary and this is block
based, not column based.
Applying a not operator has the effect of inverting all the bits. We
see that perfectly fine in ...
~00000001 = 11111110
But, when you then express that pattern in decimal, the rules
regarding 2's compliment kick in. -128 to 127 = 256 options. Not -127
to 127 ... what happened to -0?
--
Richard Quadling.
--- End Message ---
