[PHP-DEV] SHA-1 support
I can't seem to find support for the SHA-1 algorithm in PHP. I did find the mhash() function, but not only is this function very badly documented (no list of what hashes it supports!), you also have to compile PHP specifially to support it. Wouldn't it be nice with a sha1() function (like md5()). It's my impression that md5 can easily be cracked within hours or days with off the shelf hardware. It is my impression that SHA-1 hashes are magnitudes harder to crack. From what I can see, the SHA-1 algorithm is very easy to implement, but my knowledge of C is limited, and my knowledge of the Zend API is nought. André Næss -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] SHA-1 support
Markus Fischer [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... I can see a possible point with a dedicated sha1() function, but I don't see one in saying that mhash() is badly documented (even if it was, it's very easy to find the right information within seconds). The later case would vindicate a documentation report. Hm. My bad, I seem to have read only the entry on mhash() after ending up there through a search. A reference to Mhash from crc32() and md5() would be nice though, just to tell people about other hashing functions. Maybe there should also be a mention of the fact that MD5 is fairly easy to crack? Anyway, the reason why I want a dedicated SHA-1 function is that it's stronger than MD5, and that (as far as I can see) it is now the recommended hashing function, having to install some extra stuff for this purpose seems wrong to me. Regards André Næss -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] SHA-1 support
Christian Stocker [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... Who said that? Never heard of any claims, that md5 is insecure ... http://mdcrack.multimania.com/index2.html André Næss -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] SHA-1 support
Stefan Roehrich [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... On 2002-02-17 17:35:26, André Næss wrote: nice though, just to tell people about other hashing functions. Maybe there should also be a mention of the fact that MD5 is fairly easy to crack? Can you give some references? Yes, MD5 does have some weaknesses (so SHA1 would probably be better), but as far as I know it's not fairly easy to crack. (I must search the Dobbertin paper, which probably found the first serious design flaws in MD4, but IMHO no real attacks in practice until now for MD5. Are there any newer papers about this?) I just read some general discussions on the topic in misc. security related boards and got the impression that the consensus was that MD5 should be phased out and replaced by SHA-1. Also have a look at the URL in my reply to Christian Stockner. It is my impression that SHA-1 can't be easily cracked using brute-force, which is viable with MD5, and thus MD5 should be replaced by SHA-1. I might of course have misunderstood as this is not my field of expertise. André Næss -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: JavaScript --- PHP
Beta [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... Hi, I have a problem sending variable value from JAVASCRIPT to PHP Exactly what I want is when i press Submit button the javascript array to be posted in PHP, i don't want to use any HTML form. How Can i POST variable values from JavaScript Directly in PHP and not throught HTML forms You're on the wrong group, this group is for developers of PHP, please use php.general instead. André Næss -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Sessions proposal
I find PHP session lacking in one area. In my applications I typically want to have a long timeout for adminstrators so that they don't have to log in all the time. A typical value is 2 hours. For users I prefer 15 minutes, based on the assumption that a user will go in, do his stuff, and leave. For this to happen I need to have the gc_maxlifetime set to 2 hours, or risk unpredictable results for the administrators. The problem with this is of course that garbage collection will run infrequently for the entire system, even though most of the sessions expire after 15 minutes. It would therefore be nice to have something like session contexts, where you could have different session settings for each context. Is this possible to achieve? Anyone else who can see the use of this? Regards. André Næss -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: Sessions proposal
John Lim [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... Hi Andre Why not simply store the login time as a session variable, and log the person out after 15 mins? Regards, John Maybe I was unclear. The problem is that to allow for 2 hour timeouts I need to have gc_maxlifetime set to 2 hours, but for 99,9% of all session I don't need than 15 minutes gc_maxlifetime since they have a cookie lifetime of 15 minutes. Also, I can't log the user out after 15 minutes (it's better to use cookie_lifetime for that), I haven't got any idea of where he is, so storing the login time as a session variable won't let me change the gc_maxlifetime. André Næss André NæSs [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... I find PHP session lacking in one area. In my applications I typically want to have a long timeout for adminstrators so that they don't have to log in all the time. A typical value is 2 hours. For users I prefer 15 minutes, based on the assumption that a user will go in, do his stuff, and leave. For this to happen I need to have the gc_maxlifetime set to 2 hours, or risk unpredictable results for the administrators. The problem with this is of course that garbage collection will run infrequently for the entire system, even though most of the sessions expire after 15 minutes. It would therefore be nice to have something like session contexts, where you could have different session settings for each context. Is this possible to achieve? Anyone else who can see the use of this? Regards. André Næss -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Missing date() functionality
Wouldn't it be nice if date() returned the weeknumber? I was rather appalled when I realized this wasn't available... Have I missed something? The other date related functions also seem to miss functionality like this. André Næss -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
RE: [PHP-DEV] Missing date() functionality
Ok, thanks for pointing that out, but it seems rather strange to use a string function when you need to do a date operation?! I would guess that everyone looking for a way to handle dates and time would look in the date and time functions part of the manual. There should AT LEAST be a reference to strftime() from date()! André Næss -Original Message- From: Christian Joergensen [mailto:[EMAIL PROTECTED]] Sent: 15. august 2001 00:18 To: André Næss; [EMAIL PROTECTED] Subject: Re: [PHP-DEV] Missing date() functionality On Tuesday 14 August 2001 22:03, André Næss wrote: Wouldn't it be nice if date() returned the weeknumber? I was rather appalled when I realized this wasn't available... Have I missed something? The other date related functions also seem to miss functionality like this. You can do that with strftime: http://php.net/manual/en/function.strftime.php -- Christian Jørgensen | Ford, you're turning into a penguin http://www.razor.dk | Stop it -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
RE: [PHP-DEV] Portability concerns
-Original Message- [Phil Driscoll [EMAIL PROTECTED]] My thought was that it may be possible to get rid of some of the portability issues by implementing a new function php_portability() which takes TRUE or FALSE arguments to turn it on or off. The idea is that when switched on, it could modify the behaviour of certain functions dependent on the php.ini settings - e.g. addslashes or stripslashes would do nothing if magic_quotes were on in php.ini and do its normal job if they were off. Sadly the above example is complicated by having magic_quotes_gpc and magic_quotes_runtime, so it may not be possible to sort out. The other reason I didn't post yesterday, was that I could not then think of any other functions for which this kind of behaviour would work :) I don't like the idea of a function like this, I think it's much more important to educate people on how they write portable PHP code (to the extent possible). If the PHP community is going to continue flaunting PHP as a a portable language, the very same community must have guidelines on how to make it portable. Now, one of the reason that I post this is that even though I have been programming PHP for two years, and feel fairly proficient at it, I know very little about which settings are available and what they do (this has generally been handled by the syops I've been working with.) I don't think I'm alone at feeling a bit at loss when it comes to all the different options and settings and stuff that might make your script break if you upgrade, change server, or let someone else use them. So, what I would like to see is a nice set of guidelines -- W3C style -- on how to write portable PHP code. I think there are a lot of people out there who could benefit from a such document. André Næss -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
