Re: [PHP] Encryption/Decryption Question
On 12 August 2010 02:07, Josh Kehn josh.k...@gmail.com wrote: On Aug 11, 2010, at 6:50 PM, tedd wrote: Hi gang: Okay, a question to the Encryption/Decryption gurus out there. If you were given: 1. This encrypted string: p3IVhDBT26i+p4vd7J4fAw== 2. Were told it was a social security number (i.e., in the form of 123-45-6789). 3. And it had been generated from this code: $cipher = mcrypt_module_open(MCRYPT_TRIPLEDES,'','cbc',''); mcrypt_generic_init($cipher, $key1, $key2); $encrypted = mcrypt_generic($cipher,$social_security_number); 4. Where $key1 and $key2 are md5() values calculated from two different security phrases. 5. Where each security phrase contains multiple non-English words. What would it take for you to break the encrypted string and decipher the social security number? Can it be done? If so, how long? And lastly, where would the best place to store these security phrases? (Note: I didn't ask where would be the best place for me to put them.) :-) Cheers, tedd PS: No, the SS number in question is not 123-45-6789. :-) -- --- http://sperling.com/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php Tedd- Considering you can brute force the entire keyspace for Triple DES in under a few hours (without specialized equipment) I don't think it would take long. Granted, I'm not an encryption expert. I look forward to hearing more. I'd love to see sources on how to bruteforce the entire keyspace for 3DES in under a few hours without knowing the three keys involved or the IV. Googling triple des gives you http://en.wikipedia.org/wiki/Triple_DES which among other things states This is not currently practical and NIST considers keying option 1 to be appropriate through 2030. (keying option 1 being three independent keys as would be the case here). 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 -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Encryption/Decryption Question
On Wed, Aug 11, 2010 at 6:50 PM, tedd t...@sperling.com wrote: Hi gang: Okay, a question to the Encryption/Decryption gurus out there. If you were given: 1. This encrypted string: p3IVhDBT26i+p4vd7J4fAw== 2. Were told it was a social security number (i.e., in the form of 123-45-6789). 3. And it had been generated from this code: $cipher = mcrypt_module_open(MCRYPT_TRIPLEDES,'','cbc',''); mcrypt_generic_init($cipher, $key1, $key2); $encrypted = mcrypt_generic($cipher,$social_security_number); 4. Where $key1 and $key2 are md5() values calculated from two different security phrases. 5. Where each security phrase contains multiple non-English words. What would it take for you to break the encrypted string and decipher the social security number? Can it be done? If so, how long? Incentive. If cracking the encryption means you'll have one soc # without a name or other types of info, I suspect no hacker would devote the time needed to crack it. However, if this is an encryption scheme meant to protect 100's, 1000's, or millions of records that include the corresponding name, then this is asking for trouble because: 1. MD5 - Use of this old algorithm to produce your keys limits your key space due to collisions AND the fact that 3DES accepts keys longer than the 128 bit output MD5 produces. Additionally, only 64 bits of the MD5 digest are utilized in the 3DES initialization vector. 2. 3DES in CBC mode using the MD5'd passphrase as an IV - Using a constant initialization vector reveals much about the underlying consistencies in plaintext. 3DES uses block sizes of 64 bits (yuck), makes use of a relatively small key (effectively 112 bits.) And, as mentioned above, you're using a shortened key, which essentially makes the key space even smaller. 3. SS#'s - Several patterns to work from, if the table containing them was compromised, including the dashes, consistent padding, the distribution (first 3 digits related to where you applied for your soc.), etc. If the attacker happened to be an entry in the database, even worse (known plaintext.) Knowing how long it would take is pretty difficult. An attacker could start in the middle of the key space, one end, the other, break the key space up into blocks and randomly brute force them, etc. Odds are no matter how big the potential key space, the key that works won't be the last one tried, so the attempts rarely come at the very end of any brute force attack. As I've mentioned, there are several patterns in this particular scheme that would allow an attacker to short-curuit attempts that are not the correct key, and even a dumb brute force attack that requires 2 ^ 112 keys gets much smaller every day, technologically speaking. Additionally, the number of rows in the table would likely play a role, as more rows would provide incentive for throwing more processing power at the work. Of note, SS#'s are a special piece of data, not only because of their power, but because of their lifetime (normally as long as the individual lives.) This is very different from a credit card which gets updated every 5 years or so, and is easily changed if needed. You have to ask yourself if the encryption/security scheme can be counted on to protect this data many years from now. In summary, I wouldn't use this scheme for storing SS#'s in a large DB, as it would keep me awake at night. If the DB was ever compromised, I would NOT HAVE CONFIDENCE IN THE ENCRYPTION'S ABILITY TO PROTECT THE SS#'s. The probabilities are just to poor when compared to other, better algorithms/schemes available. However, if this is just a Tedd special for storing a few SS#'s on your home computer/network, I wouldn't worry too much because 1) it's your SS#, not mine, and more importantly 2) such a small set of SS#'s wouldn't be analyzed because it wouldn't merit the processing power/time (unless you get really, really rich really really quick ;) And lastly, where would the best place to store these security phrases? (Note: I didn't ask where would be the best place for me to put them.) :-) Might as well post them on your website with this scheme. (OK, don't flame me, just joking with that one.) Bastiens's points about storage are on spot. I would store the credentials (in memory, you'd have to reenter them when you reboot) on a separate machine which would handle all of the encrypted data processing (the DB server would merely hand-off the encrypted data.) Cheers, tedd PS: No, the SS number in question is not 123-45-6789. :-) -- --- http://sperling.com/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php Adam -- Nephtali: PHP web framework that functions beautifully http://nephtaliproject.com
Re: [PHP] Encryption/Decryption Question
On 12 August 2010 09:48, Adam Richardson simples...@gmail.com wrote: On Wed, Aug 11, 2010 at 6:50 PM, tedd t...@sperling.com wrote: *snip* 1. MD5 - Use of this old algorithm to produce your keys limits your key space due to collisions AND the fact that 3DES accepts keys longer than the 128 bit output MD5 produces. Additionally, only 64 bits of the MD5 digest are utilized in the 3DES initialization vector. Good point about the key based on md5. Whether or not the key would be too short depends upon how md5() was used though - if the default was used, the key would be long enough (32 char string) but even weaker - keyspace of 16^24 vs. 128^16. 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 -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Encryption/Decryption Question
At 8:09 PM -0400 8/11/10, Bastien Koert wrote: From my experience, I'd have to say that it would be a real tough go to crack that. If there was a weak point in the scheme is that your end result pattern ( the ssn ) is defined with a pair of constants, the hyphens. In our scheme we remove the dashes and just provide a mask for display. We also keep a unique key with each ssn, the record number for extra security. The SS numbers can be stored in any format (with/without hyphens, reversed, transposed, predetermined mixing, whatever). Of course, there can be another field where a unique key is kept, but I'm not sure how that might improve security. Where to keep it is tougher, OWASP suggests that the keys be stored on another non web facing server, with a locked down filesystem. That would be best if you have the hardware available. So that I understand, you are talking about two web sites where one (domain1.com) would contain/run the scripts and the other (domain2.com) contained the keys. It would work like so: When the script launches in domain1.com, the script would ask (after authorization) domain2.com for the keys, which are kept in a locked directory. After which the Encryption/Decryption scheme would work. Is that it? One other option here is to load the keys into ram on server start up and never have them physically on the machine. I'm not sure as to how to make that work. But I assume that it requires a dedicated server, right? Cheers, tedd -- --- http://sperling.com/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Encryption/Decryption Question
At 3:48 AM -0400 8/12/10, Adam Richardson wrote: -- snip excellent points -- Of note, SS#'s are a special piece of data, not only because of their power, but because of their lifetime (normally as long as the individual lives.) This is very different from a credit card which gets updated every 5 years or so, and is easily changed if needed. You have to ask yourself if the encryption/security scheme can be counted on to protect this data many years from now. Agreed and understood. In summary, I wouldn't use this scheme for storing SS#'s in a large DB, as it would keep me awake at night. If the DB was ever compromised, I would NOT HAVE CONFIDENCE IN THE ENCRYPTION'S ABILITY TO PROTECT THE SS#'s. The probabilities are just to poor when compared to other, better algorithms/schemes available. What do you recommend? Do you have code/reference? However, if this is just a Tedd special for storing a few SS#'s on your home computer/network, I wouldn't worry too much because 1) it's your SS#, not mine, and more importantly 2) such a small set of SS#'s wouldn't be analyzed because it wouldn't merit the processing power/time (unless you get really, really rich really really quick ;) :-) This isn't a Tedd's special for storing my SS#'s on my own computer, but rather an honest attempt to better understand and implement a prudent Encryption/Decryption scheme. Not that you said otherwise, but I am capable of understanding how these things work. My problem is that I am not current on what practice is best. It seems to me that things change so fast that when you become to rely on one solution, it goes out of date and is replaced with something else. Cheers, tedd -- --- http://sperling.com/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Encryption/Decryption Question
From: tedd At 8:09 PM -0400 8/11/10, Bastien Koert wrote: From my experience, I'd have to say that it would be a real tough go to crack that. If there was a weak point in the scheme is that your end result pattern ( the ssn ) is defined with a pair of constants, the hyphens. In our scheme we remove the dashes and just provide a mask for display. We also keep a unique key with each ssn, the record number for extra security. The SS numbers can be stored in any format (with/without hyphens, reversed, transposed, predetermined mixing, whatever). Of course, there can be another field where a unique key is kept, but I'm not sure how that might improve security. Where to keep it is tougher, OWASP suggests that the keys be stored on another non web facing server, with a locked down filesystem. That would be best if you have the hardware available. So that I understand, you are talking about two web sites where one (domain1.com) would contain/run the scripts and the other (domain2.com) contained the keys. It would work like so: When the script launches in domain1.com, the script would ask (after authorization) domain2.com for the keys, which are kept in a locked directory. After which the Encryption/Decryption scheme would work. Is that it? One other option here is to load the keys into ram on server start up and never have them physically on the machine. I'm not sure as to how to make that work. But I assume that it requires a dedicated server, right? If I might make a suggestion or two. 1. Put all of the data on a separate DB server that is not accessible from the Internet, but only through authorized access to the web server. The data should still be encrypted, but at least you can eliminated brute force attacks. Even though the data is necessary for your client's business, it is still privileged information as far as his targets and the government are concerned. Treat it accordingly. 2. Spend some time reading all of the OWASP[1] guidelines and implement as many of them as you feasibly can. That might cost some time (and money) but will be better for your client in the long run. He reduces both his exposure and liability while still being able to use that data. 3. Spend some time reading the PCI requirements in your country and try to implement as many of those as possible. But keep in mind that they exist solely to protect the credit card issuers. You need to figure out how far you need to go in order to protect your client. Bob McConnell [1] http://www.owasp.org/index.php/Main_Page -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Encryption/Decryption Question
On Thu, Aug 12, 2010 at 10:00 AM, tedd t...@sperling.com wrote: At 8:09 PM -0400 8/11/10, Bastien Koert wrote: From my experience, I'd have to say that it would be a real tough go to crack that. If there was a weak point in the scheme is that your end result pattern ( the ssn ) is defined with a pair of constants, the hyphens. In our scheme we remove the dashes and just provide a mask for display. We also keep a unique key with each ssn, the record number for extra security. The SS numbers can be stored in any format (with/without hyphens, reversed, transposed, predetermined mixing, whatever). Of course, there can be another field where a unique key is kept, but I'm not sure how that might improve security. Just adds another layer to it. Where to keep it is tougher, OWASP suggests that the keys be stored on another non web facing server, with a locked down filesystem. That would be best if you have the hardware available. So that I understand, you are talking about two web sites where one (domain1.com) would contain/run the scripts and the other (domain2.com) contained the keys. It would work like so: When the script launches in domain1.com, the script would ask (after authorization) domain2.com for the keys, which are kept in a locked directory. After which the Encryption/Decryption scheme would work. Is that it? correct One other option here is to load the keys into ram on server start up and never have them physically on the machine. I'm not sure as to how to make that work. But I assume that it requires a dedicated server, right? Yes, you would need a non web facing machine Cheers, tedd -- --- http://sperling.com/ -- Bastien Cat, the other other white meat -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Encryption/Decryption Question
On Aug 11, 2010, at 6:50 PM, tedd wrote: Hi gang: Okay, a question to the Encryption/Decryption gurus out there. If you were given: 1. This encrypted string: p3IVhDBT26i+p4vd7J4fAw== 2. Were told it was a social security number (i.e., in the form of 123-45-6789). 3. And it had been generated from this code: $cipher = mcrypt_module_open(MCRYPT_TRIPLEDES,'','cbc',''); mcrypt_generic_init($cipher, $key1, $key2); $encrypted = mcrypt_generic($cipher,$social_security_number); 4. Where $key1 and $key2 are md5() values calculated from two different security phrases. 5. Where each security phrase contains multiple non-English words. What would it take for you to break the encrypted string and decipher the social security number? Can it be done? If so, how long? And lastly, where would the best place to store these security phrases? (Note: I didn't ask where would be the best place for me to put them.) :-) Cheers, tedd PS: No, the SS number in question is not 123-45-6789. :-) -- --- http://sperling.com/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php Tedd- Considering you can brute force the entire keyspace for Triple DES in under a few hours (without specialized equipment) I don't think it would take long. Granted, I'm not an encryption expert. I look forward to hearing more. Thanks, -Josh Joshua Kehn | josh.k...@gmail.com http://joshuakehn.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Encryption/Decryption Question
From my experience, I'd have to say that it would be a real tough go to crack that. If there was a weak point in the scheme is that your end result pattern ( the ssn ) is defined with a pair of constants, the hyphens. In our scheme we remove the dashes and just provide a mask for display. We also keep a unique key with each ssn, the record number for extra security. Where to keep it is tougher, OWASP suggests that the keys be stored on another non web facing server, with a locked down filesystem. That would be best if you have the hardware available. One other option here is to load the keys into ram on server start up and never have them physically on the machine. Bastien On 8/11/10, tedd t...@sperling.com wrote: Hi gang: Okay, a question to the Encryption/Decryption gurus out there. If you were given: 1. This encrypted string: p3IVhDBT26i+p4vd7J4fAw== 2. Were told it was a social security number (i.e., in the form of 123-45-6789). 3. And it had been generated from this code: $cipher = mcrypt_module_open(MCRYPT_TRIPLEDES,'','cbc',''); mcrypt_generic_init($cipher, $key1, $key2); $encrypted = mcrypt_generic($cipher,$social_security_number); 4. Where $key1 and $key2 are md5() values calculated from two different security phrases. 5. Where each security phrase contains multiple non-English words. What would it take for you to break the encrypted string and decipher the social security number? Can it be done? If so, how long? And lastly, where would the best place to store these security phrases? (Note: I didn't ask where would be the best place for me to put them.) :-) Cheers, tedd PS: No, the SS number in question is not 123-45-6789. :-) -- --- http://sperling.com/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- Sent from my mobile device Bastien Cat, the other other white meat -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Encryption/decryption of PHP data
Edward Diener wrote: Phpster wrote: In reading the license I believe it refers to the gnupg itself, not the application it may be embedded in. You are completely free to use gnupg as you choose including modifying it to meet your needs. I always thought the GNU public license demanded that any non-free modules, which use any software distributed with this license, make their source code freely available to end users. If this is either not the case or no longer the case, then I will be glad to use GnuPG. If you are distributing or selling your non-GPL software and you use GPL software with it, then yes, I believe you are required to make your source code available to the end-user too. Maybe have a quick look at http://gpl-violations.org/ /Per Jessen, Zürich -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Encryption/decryption of PHP data
if you want client to send encrypted form to server. then it must be done using some kind of client side script (javascript?). i don't think it is reliable. why not just use https protocol. all data between client and server will be encrypted. On 1/1/09, Per Jessen p...@computer.org wrote: Edward Diener wrote: Phpster wrote: In reading the license I believe it refers to the gnupg itself, not the application it may be embedded in. You are completely free to use gnupg as you choose including modifying it to meet your needs. I always thought the GNU public license demanded that any non-free modules, which use any software distributed with this license, make their source code freely available to end users. If this is either not the case or no longer the case, then I will be glad to use GnuPG. If you are distributing or selling your non-GPL software and you use GPL software with it, then yes, I believe you are required to make your source code available to the end-user too. Maybe have a quick look at http://gpl-violations.org/ /Per Jessen, Zürich -- 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] Encryption/decryption of PHP data
Per Jessen wrote: Edward Diener wrote: Phpster wrote: In reading the license I believe it refers to the gnupg itself, not the application it may be embedded in. You are completely free to use gnupg as you choose including modifying it to meet your needs. I always thought the GNU public license demanded that any non-free modules, which use any software distributed with this license, make their source code freely available to end users. If this is either not the case or no longer the case, then I will be glad to use GnuPG. If you are distributing or selling your non-GPL software and you use GPL software with it, then yes, I believe you are required to make your source code available to the end-user too. The project in which I am working is definitely selling the software and we have no intention of distributing the source code with it. So that leaves GnuPG out. Is there any other PHP public key-private key implementation which I can use which either I will pay for or does not use the Gnu Public license ? -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Encryption/decryption of PHP data
paragasu wrote: if you want client to send encrypted form to server. then it must be done using some kind of client side script (javascript?). I am using C++. i don't think it is reliable. Why would it not be reliable if I were using a public-key/private-key encryption library which works both with PHP and C++ ? why not just use https protocol. all data between client and server will be encrypted. The data must be encrypted/decrypted going both ways between the client and the server. Does using https automatically do that ? If it does that would be great. On 1/1/09, Per Jessen p...@computer.org wrote: Edward Diener wrote: Phpster wrote: In reading the license I believe it refers to the gnupg itself, not the application it may be embedded in. You are completely free to use gnupg as you choose including modifying it to meet your needs. I always thought the GNU public license demanded that any non-free modules, which use any software distributed with this license, make their source code freely available to end users. If this is either not the case or no longer the case, then I will be glad to use GnuPG. If you are distributing or selling your non-GPL software and you use GPL software with it, then yes, I believe you are required to make your source code available to the end-user too. Maybe have a quick look at http://gpl-violations.org/ /Per Jessen, Zürich -- 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] Encryption/decryption of PHP data
Edward Diener wrote: why not just use https protocol. all data between client and server will be encrypted. The data must be encrypted/decrypted going both ways between the client and the server. Does using https automatically do that ? If it does that would be great. Yes, that is exactly what https does. /Per Jessen, Zürich -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Encryption/decryption of PHP data
In reading the license I believe it refers to the gnupg itself, not the application it may be embedded in. You are completely free to use gnupg as you choose including modifying it to meet your needs. Bastien Sent from my iPod On Dec 30, 2008, at 10:50 PM, Edward Diener el...@tropicsoft.com wrote: My client application needs to send data to a PHP page in encrypted form and have the PHP code able to decrypt it. Likewise the PHP code needs to return data to my application encrypted and my client application needs to be able to decrypt it. My application is written in C++ and naturally the PHP page is written in PHP. I do understand that public key-private key cryptography is the way to go. So far my Internet search has turrned up GnuPG as a means of doing public key-private key cryptography for PHP with libraries for C++ also. However the client application is a commercial application and unless I misunderstand the GNU General Public License the software of the application which uses GnuPG must allow its source to be freely available in order to use the library. This is of course something which I am completely unwilling to do for the commercial application. Is there any other public key-private key cryptography solution on the PHP side which also has a C++ library which I can use for the client application, which does not adhere to the GNU General Public License ? This does not have to be a free product. -- 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] Encryption/decryption of PHP data
As I understand it: You can LINK your commercial binary with GPL binaries, and keep closed source. You cannot co-mingle the two C source codes together and keep it closed. I am fairly certain you can find commercial C++ offerings to generate PGP key pairs, instead of using the GnuPG OSS alternative... -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Encryption/decryption of PHP data
Phpster wrote: In reading the license I believe it refers to the gnupg itself, not the application it may be embedded in. You are completely free to use gnupg as you choose including modifying it to meet your needs. I always thought the GNU public license demanded that any non-free modules, which use any software distributed with this license, make their source code freely available to end users. If this is either not the case or no longer the case, then I will be glad to use GnuPG. Bastien Sent from my iPod On Dec 30, 2008, at 10:50 PM, Edward Diener el...@tropicsoft.com wrote: My client application needs to send data to a PHP page in encrypted form and have the PHP code able to decrypt it. Likewise the PHP code needs to return data to my application encrypted and my client application needs to be able to decrypt it. My application is written in C++ and naturally the PHP page is written in PHP. I do understand that public key-private key cryptography is the way to go. So far my Internet search has turrned up GnuPG as a means of doing public key-private key cryptography for PHP with libraries for C++ also. However the client application is a commercial application and unless I misunderstand the GNU General Public License the software of the application which uses GnuPG must allow its source to be freely available in order to use the library. This is of course something which I am completely unwilling to do for the commercial application. Is there any other public key-private key cryptography solution on the PHP side which also has a C++ library which I can use for the client application, which does not adhere to the GNU General Public License ? This does not have to be a free product. -- 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] Encryption failing
2008. 01. 17, csütörtök keltezéssel 12.14-kor Ken Kixmoeller -- reply to [EMAIL PROTECTED] ezt írta: (forgot to copy the list) On Jan 16, 2008, at 5:08 PM, Richard Lynch wrote: Is it possible that 4% of the time, you have spaces on the start/end of the string, which get trimmed before encryption? In this case, no. In trying to simplify the situation to narrow the possibilities of error, I am generating random character strings of only alphanumeric (or numeric-only) characters. Each is exactly 16 characters. And if rijndael is one of the algorithms which requires a fixed-size input, that also would be bad to trim it. No documentation that I was able to find suggests that requirement. Actually, I'd suggest that the encryption function has no business trimming the text anyway. Philosophically I agree with you, but mCrypt has this nasty habit of appending bunches of nulls to the decrypted string. So philosophical purity gives way to practical application. yeah, I just ran into the same thing yesterday evening with mcrypt and rijndael_256. encrypting went fine, decrypted string had a lot of nulls at the end. so I too had to use trim() on it. greets Zoltán Németh Good ideas, as usual. Thank you. Ken -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Encryption failing
(forgot to copy the list) On Jan 16, 2008, at 5:08 PM, Richard Lynch wrote: Is it possible that 4% of the time, you have spaces on the start/end of the string, which get trimmed before encryption? In this case, no. In trying to simplify the situation to narrow the possibilities of error, I am generating random character strings of only alphanumeric (or numeric-only) characters. Each is exactly 16 characters. And if rijndael is one of the algorithms which requires a fixed-size input, that also would be bad to trim it. No documentation that I was able to find suggests that requirement. Actually, I'd suggest that the encryption function has no business trimming the text anyway. Philosophically I agree with you, but mCrypt has this nasty habit of appending bunches of nulls to the decrypted string. So philosophical purity gives way to practical application. Good ideas, as usual. Thank you. Ken -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Encryption failing
On Jan 15, 2008, at 10:48 PM, Casey wrote: It returns the correct value. If you look at the last example, and run base64_decode on MDAwMzEwMDI0NDA0MTMyOQ==, you will get 0003100244041329. Oops. Haste makes crappy programming. Ken -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Encryption failing
On Jan 16, 2008, at 1:28 AM, Andrés Robinet wrote: 1 - Mike is right about first encrypting and then doing a base64_encode (then saving results to DB, cookies, etc). I don't know why replacing to + for decrypting, though. His other post explains that php didn't seem to like spaces. No spaces in the test strings -- I'll check for those when/if I can get the core en/decryption working. 2 - Mike is also right about $text = base64_decode($text) which should be $text = base64_decode($text_out) I think. Yup -- that's what i get for trying to do this hastily and late at night -- 3 - You are trimming the results on return, according to one post in the manual notes this will remove null padding on the decrypted string. This is desired, most of the time, but if the original (cleartext message) string ended in nulls you will get a difference and that may be the cause of the errors you are getting. I understand that, thank you. There are no trailing nulls on the original string. After correcting the my program, I still get the same results, about 4% wrong: 70: String: 5214006139804600 -|- Enc: Ϊ%bÇCsšBsìD%Å#z[ä . m…‡¿m§ð -|- Dec:àc8 -|- Nope 75: String: 1034702254251899 -|- Enc: !:Ã2ºÍé× »àe 2s? :Ù0LµŒÕ[« -|- Dec:à`*' -|- Nope 89: String: 8245007043826594 -|- Enc: µÆ Íãd-‘Á´E3½yÍ×v‹,ZØWéûqüŽ‚ó -|- Dec:[EMAIL PROTECTED] -|- Nope etc. Wrong: 23/500 Phooey. Ken -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Encryption failing
On 1/16/08, Ken Kixmoeller -- reply to [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
On Jan 16, 2008, at 1:28 AM, Andrés Robinet wrote:
His other post explains that php didn't seem to like spaces. No
spaces in the test strings -- I'll check for those when/if I can get
the core en/decryption working.
See below - I had an issue with a .NET encrypted string in a cookie
and decrypting it in PHP. It was required for that. I think it might
be due to how .NET does it's base64 encoding; but I've kept it in my
code just in case even for pure PHP.
Here are my encrypt/decrypt functions. This is -not- the previous
.NET/PHP exchange I mentioned. That uses a weaker bit AES due to
.NET's defaults
function data_encrypt($data) {
if(!$data) { return false; }
return base64_encode(mcrypt_encrypt(MCRYPT_RIJNDAEL_256,
$GLOBALS['config']['salt'], $data, 'cbc', md5($GLOBALS['config']['
salt'].$GLOBALS['config']['salt'])));
}
function data_decrypt($data) {
if(!$data) { return false; }
return rtrim(mcrypt_decrypt(MCRYPT_RIJNDAEL_256,
$GLOBALS['config']['salt'], base64_decode(str_replace(' ', '+',
$data)), '
cbc', md5($GLOBALS['config']['salt'].$GLOBALS['config']['salt'])));
}
where $config['salt'] in a config file is your random key. make it
something worthwhile like haX0r$sUCK! that won't ever be easily
guessed.
I have code like this running on a couple sites - works like a charm,
that includes using it to encrypt cookie data and decrypt it on the
way back. I am not entirely sure if the str_replace for the spaces is
-required- for a PHP to PHP encryption/decryption, but it doesn't seem
to hurt, and I don't believe this should fail for any reason in your
tests...
The one caveat is I think it is suggested to use the mcrypt_generic()
functions now, which I believe meant writing a bunch more lines of
code and I liked my single line solution (and I might have had an
issue for some reason trying to make it work... I'll probably have to
redo this someday either way)
Re: [PHP] Encryption failing
Many thanks, Mike --- yours works great... 0 errors.
On Jan 16, 2008, at 9:24 AM, mike wrote:
function data_encrypt($data) {
if(!$data) { return false; }
return base64_encode(mcrypt_encrypt(MCRYPT_RIJNDAEL_256,
$GLOBALS['config']['salt'], $data, 'cbc', md5($GLOBALS['config']['
salt'].$GLOBALS['config']['salt'])));
}
function data_decrypt($data) {
if(!$data) { return false; }
return rtrim(mcrypt_decrypt(MCRYPT_RIJNDAEL_256,
$GLOBALS['config']['salt'], base64_decode(str_replace(' ', '+',
$data)), '
cbc', md5($GLOBALS['config']['salt'].$GLOBALS['config']['salt'])));
}
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Encryption failing
On Tue, January 15, 2008 10:48 pm, Casey wrote:
On Jan 15, 2008 8:40 PM, Ken Kixmoeller -- reply to [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
On Jan 15, 2008, at 11:08 PM, Andrés Robinet wrote:
I second that, you should base64 encode values before encrypting
and base64
decode them after decrypting to be safe.
Thanks for the idea.
Like this? Fails 500/500 times on my test.
if ($EorD == D) {
$text_out = mdecrypt_generic($cypher,$text);
You are base64-ing it, but...
$text = base64_decode($text);
You are not decoding the base64, but the original.
} else {
$text= base64_encode($text);
$text_out = mcrypt_generic($cypher,$text);
} // endif ($EorD == D)
A quick test looks like this:
1: String: 9334133814260182
-|- Enc: X5Þ(c)·a`p#È]#c¦±3 ÔýCõÒiÏ~r ¢Tª
-|- Dec:OTMzNDEzMzgxNDI2MDE4Mg== -|- Nope
2: String: 3027022406512648
-|- Enc: j£n,h\m ê´ uKP%¥ ¼D }H'f ¢
-|- Dec:MzAyNzAyMjQwNjUxMjY0OA== -|- Nope
3: String: 5042504153020331
-|- Enc: 9ÿ ýݧ¤6Wi+×éáon ñº*J 6}Ø+
-|- Dec:NTA0MjUwNDE1MzAyMDMzMQ== -|- Nope
4: String: 6741156238850410
-|- Enc: · :´[Úq\ë 4\Q«Í5±{ºµØtþðtN?b
-|- Dec:Njc0MTE1NjIzODg1MDQxMA== -|- Nope
5: String: 0003100244041329
-|- Enc: D¾¤ úV:!Mû 4ÜàòÐÐ^ï Hñ- %z
-|- Dec:MDAwMzEwMDI0NDA0MTMyOQ== -|- Nope
Wrong: 5/5
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
It returns the correct value. If you look at the last example, and run
base64_decode on MDAwMzEwMDI0NDA0MTMyOQ==, you will get
0003100244041329.
-Casey
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
--
Some people have a gift link here.
Know what I want?
I want you to buy a CD from some indie artist.
http://cdbaby.com/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] Encryption failing
Is it possible that 4% of the time, you have spaces on the start/end
of the string, which get trimmed before encryption?
And if rijndael is one of the algorithms which requires a fixed-size
input, that also would be bad to trim it. If you need multiple of
16 bytes input, leave the input alone.
Actually, I'd suggest that the encryption function has no business
trimming the text anyway.
If I want to jagencdecr(str_repeat(' ', 1000), 'E'), then I probably
don't want the function to trim that, eh? :-)
On Tue, January 15, 2008 6:54 pm, Ken Kixmoeller -- reply to
[EMAIL PROTECTED] wrote:
Hey --- - -
I am in the process of upgrading the encryption technology I am using
from (64 bit) blowfish to (256 bit) rijndael.
The code (and some explanations) is below, but the results are, um,
unusual, and I can't see what I am doing wrong. For testing, I have a
program that generates a random 16-character string, encrypts it to a
variable, and decrypts it. Running it in 500 iteration loops, it
fails roughly 4% of the time. By fails I mean that the original
string and the eventual decrypted one don't match.
Anybody able to spot why?
Ken
--
function jagencdecr($text,$EorD,$encpass='') {
// parameters:
// - $text = string to be en/decrypted,
// - $EorD = Encrypt or Decrypt
// - $encpass = key phrase
if (empty($text)) {return ;}
$text = trim($text);
$cypher = mcrypt_module_open('rijndael-256', '', 'ecb', '');
// ecb mode produces the above results.
// ofb mode produces 100% errors
$size = mcrypt_enc_get_iv_size($cypher);
$phprand = rand(1000,);
$iv = mcrypt_create_iv($size,$phprand); // produces the same results
as below, platform independent
//$iv = mcrypt_create_iv($size,MCRYPT_RAND); // for Windows
//$iv = mcrypt_create_iv($size,MCRYPT_DEV_RAND); // for 'NIX
$ks = mcrypt_enc_get_key_size($cypher);
/* Create key */
$key = substr(md5($encpass), 0, $ks);
mcrypt_generic_init($cypher,$key,$iv);
if ($EorD == D) {
$text_out = mdecrypt_generic($cypher,$text);
} else {
$text_out = mcrypt_generic($cypher,$text);
} // endif ($EorD == D)
mcrypt_generic_deinit($cypher);
mcrypt_module_close($cypher);
return trim($text_out);
} // endfunc jagencdecr Jaguar Ecnrypt/Decrypt
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
--
Some people have a gift link here.
Know what I want?
I want you to buy a CD from some indie artist.
http://cdbaby.com/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] Encryption failing
On Jan 15, 2008, at 4:54 PM, Ken Kixmoeller -- reply to [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
Hey --- - -
I am in the process of upgrading the encryption technology I am
using from (64 bit) blowfish to (256 bit) rijndael.
The code (and some explanations) is below, but the results are, um,
unusual, and I can't see what I am doing wrong. For testing, I have
a program that generates a random 16-character string, encrypts it
to a variable, and decrypts it. Running it in 500 iteration loops,
it fails roughly 4% of the time. By fails I mean that the original
string and the eventual decrypted one don't match.
Anybody able to spot why?
Ken
--
function jagencdecr($text,$EorD,$encpass='') {
// parameters:
// - $text = string to be en/decrypted,
// - $EorD = Encrypt or Decrypt
// - $encpass = key phrase
if (empty($text)) {return ;}
$text = trim($text);
$cypher = mcrypt_module_open('rijndael-256', '', 'ecb', '');
// ecb mode produces the above results.
// ofb mode produces 100% errors
$size = mcrypt_enc_get_iv_size($cypher);
$phprand = rand(1000,);
$iv = mcrypt_create_iv($size,$phprand); // produces the same
results as below, platform independent
//$iv = mcrypt_create_iv($size,MCRYPT_RAND); // for Windows
//$iv = mcrypt_create_iv($size,MCRYPT_DEV_RAND); // for 'NIX
$ks = mcrypt_enc_get_key_size($cypher);
/* Create key */
$key = substr(md5($encpass), 0, $ks);
mcrypt_generic_init($cypher,$key,$iv);
if ($EorD == D) {
$text_out = mdecrypt_generic($cypher,$text);
} else {
$text_out = mcrypt_generic($cypher,$text);
} // endif ($EorD == D)
mcrypt_generic_deinit($cypher);
mcrypt_module_close($cypher);
return trim($text_out);
} // endfunc jagencdecr Jaguar Ecnrypt/Decrypt
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Maybe you could echo the results of the failed ones and compare.
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Encryption failing
On Jan 15, 2008, at 7:06 PM, Casey wrote: Maybe you could echo the results of the failed ones and compare. I did that at first, thinking that something about these strings might cause the problem. But then I realized: I can't blame the data. I don't have any control over what users use for passwords, for example. this thing is supposed to en/decrypt the strings I gige it, so there must be some kind of programming flaw. FWIW, there was no discernible pattern to the failed strings, at least not to me. (Not that it matters.) Ken -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Encryption failing
are you base64 encoding the resultant encryption string? I have found that there are problems with certain characters that can result from the encryption, usually a combination of characters that approximate a null or end of line bastien From: [EMAIL PROTECTED] Date: Tue, 15 Jan 2008 21:41:45 -0600 To: php-general@lists.php.net Subject: Re: [PHP] Encryption failing On Jan 15, 2008, at 7:06 PM, Casey wrote: Maybe you could echo the results of the failed ones and compare. I did that at first, thinking that something about these strings might cause the problem. But then I realized: I can't blame the data. I don't have any control over what users use for passwords, for example. this thing is supposed to en/decrypt the strings I gige it, so there must be some kind of programming flaw. FWIW, there was no discernible pattern to the failed strings, at least not to me. (Not that it matters.) Ken -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php _
Re: [PHP] Encryption failing
me too - it was a space. i changed it to + and it worked fine.
$cookie = str_replace(' ', '+', $_COOKIE['foo']);
On 1/15/08, Bastien Koert [EMAIL PROTECTED] wrote:
are you base64 encoding the resultant encryption string? I have found that
there are problems with certain characters that can result from the
encryption, usually a combination of characters that approximate a null or
end of line
bastien From: [EMAIL PROTECTED] Date: Tue, 15 Jan 2008 21:41:45 -0600 To:
php-general@lists.php.net Subject: Re: [PHP] Encryption failing On Jan
15, 2008, at 7:06 PM, Casey wrote: Maybe you could echo the results of
the failed ones and compare. I did that at first, thinking that something
about these strings might cause the problem. But then I realized: I can't
blame the data. I don't have any control over what users use for passwords,
for example. this thing is supposed to en/decrypt the strings I gige it,
so there must be some kind of programming flaw. FWIW, there was no
discernible pattern to the failed strings, at least not to me. (Not that it
matters.) Ken -- 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] Encryption failing
-Original Message- From: Bastien Koert [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 16, 2008 12:55 AM To: Ken Kixmoeller -- reply to [EMAIL PROTECTED]; php- [EMAIL PROTECTED] Subject: RE: [PHP] Encryption failing are you base64 encoding the resultant encryption string? I have found that there are problems with certain characters that can result from the encryption, usually a combination of characters that approximate a null or end of line bastien From: [EMAIL PROTECTED] Date: Tue, 15 Jan 2008 21:41:45 - 0600 To: php-general@lists.php.net Subject: Re: [PHP] Encryption failing On Jan 15, 2008, at 7:06 PM, Casey wrote: Maybe you could echo the results of the failed ones and compare. I did that at first, thinking that something about these strings might cause the problem. But then I realized: I can't blame the data. I don't have any control over what users use for passwords, for example. this thing is supposed to en/decrypt the strings I gige it, so there must be some kind of programming flaw. FWIW, there was no discernible pattern to the failed strings, at least not to me. (Not that it matters.) Ken -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php I second that, you should base64 encode values before encrypting and base64 decode them after decrypting to be safe. Rob Andrés Robinet | Lead Developer | BESTPLACE CORPORATION 5100 Bayview Drive 206, Royal Lauderdale Landings, Fort Lauderdale, FL 33308 | TEL 954-607-4207 | FAX 954-337-2695 Email: [EMAIL PROTECTED] | MSN Chat: [EMAIL PROTECTED] | SKYPE: bestplace | Web: http://www.bestplace.biz | Web: http://www.seo-diy.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Encryption failing
On Jan 15, 2008, at 11:08 PM, Andrés Robinet wrote: -Original Message- From: Bastien Koert [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 16, 2008 12:55 AM To: Ken Kixmoeller -- reply to [EMAIL PROTECTED]; php- [EMAIL PROTECTED] Subject: RE: [PHP] Encryption failing are you base64 encoding the resultant encryption string? I have found that there are problems with certain characters that can result from the encryption, usually a combination of characters that approximate a null or end of line bastien From: [EMAIL PROTECTED] Date: Tue, 15 Jan 2008 21:41:45 - 0600 To: php-general@lists.php.net Subject: Re: [PHP] Encryption failing On Jan 15, 2008, at 7:06 PM, Casey wrote: Maybe you could echo the results of the failed ones and compare. I did that at first, thinking that something about these strings might cause the problem. But then I realized: I can't blame the data. I don't have any control over what users use for passwords, for example. this thing is supposed to en/decrypt the strings I gige it, so there must be some kind of programming flaw. FWIW, there was no discernible pattern to the failed strings, at least not to me. (Not that it matters.) Ken -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php I second that, you should base64 encode values before encrypting and base64 decode them after decrypting to be safe. Rob Andrés Robinet | Lead Developer | BESTPLACE CORPORATION 5100 Bayview Drive 206, Royal Lauderdale Landings, Fort Lauderdale, FL 33308 | TEL 954-607-4207 | FAX 954-337-2695 Email: [EMAIL PROTECTED] | MSN Chat: [EMAIL PROTECTED] | SKYPE: bestplace | Web: http://www.bestplace.biz | Web: http://www.seo- diy.com -- 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] Encryption failing
On Jan 15, 2008, at 11:08 PM, Andrés Robinet wrote:
I second that, you should base64 encode values before encrypting
and base64
decode them after decrypting to be safe.
Thanks for the idea.
Like this? Fails 500/500 times on my test.
if ($EorD == D) {
$text_out = mdecrypt_generic($cypher,$text);
$text = base64_decode($text);
} else {
$text= base64_encode($text);
$text_out = mcrypt_generic($cypher,$text);
} // endif ($EorD == D)
A quick test looks like this:
1: String: 9334133814260182
-|- Enc: X5Þ©·ža`p#È]#c¦±3ÔýCõÒiÏ~r¢Tª
-|- Dec:OTMzNDEzMzgxNDI2MDE4Mg== -|- Nope
2: String: 3027022406512648
-|- Enc: j£n,h\mê´ uKP%¥†¼D}H‚’f¢š„
-|- Dec:MzAyNzAyMjQwNjUxMjY0OA== -|- Nope
3: String: 5042504153020331
-|- Enc: 9ÿ• ýŸÝ§¤6Wi+€×Ÿéáonñº*J6}Ø+„
-|- Dec:NTA0MjUwNDE1MzAyMDMzMQ== -|- Nope
4: String: 6741156238850410
-|- Enc: ·:´[Úq\‹ë‹4\Q«ÍŽ5±{º‡µØtþðtN?b
-|- Dec:Njc0MTE1NjIzODg1MDQxMA== -|- Nope
5: String: 0003100244041329
-|- Enc: D¾¤ úV:!Mû 4ƒÜ€àœ‰ŽòÐÐ^ïHñ-š%z
-|- Dec:MDAwMzEwMDI0NDA0MTMyOQ== -|- Nope
Wrong: 5/5
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Encryption failing
On Jan 15, 2008, at 11:08 PM, Andrés Robinet wrote:
I second that, you should base64 encode values before encrypting
and base64
decode them after decrypting to be safe.
Thanks for the idea.
Like this? Fails 500/500 times on my test.
if ($EorD == D) {
$text_out = mdecrypt_generic($cypher,$text);
$text = base64_decode($text);
} else {
$text= base64_encode($text);
$text_out = mcrypt_generic($cypher,$text);
} // endif ($EorD == D)
A quick test looks like this:
1: String: 9334133814260182
-|- Enc: X5Þ©·ža`p#È]#c¦±3ÔýCõÒiÏ~r¢Tª
-|- Dec:OTMzNDEzMzgxNDI2MDE4Mg== -|- Nope
2: String: 3027022406512648
-|- Enc: j£n,h\mê´ uKP%¥†¼D}H‚’f¢š„
-|- Dec:MzAyNzAyMjQwNjUxMjY0OA== -|- Nope
3: String: 5042504153020331
-|- Enc: 9ÿ• ýŸÝ§¤6Wi+€×Ÿéáonñº*J6}Ø+„
-|- Dec:NTA0MjUwNDE1MzAyMDMzMQ== -|- Nope
4: String: 6741156238850410
-|- Enc: ·:´[Úq\‹ë‹4\Q«ÍŽ5±{º‡µØtþðtN?b
-|- Dec:Njc0MTE1NjIzODg1MDQxMA== -|- Nope
5: String: 0003100244041329
-|- Enc: D¾¤ úV:!Mû 4ƒÜ€àœ‰ŽòÐÐ^ïHñ-š%z
-|- Dec:MDAwMzEwMDI0NDA0MTMyOQ== -|- Nope
Wrong: 5/5
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Encryption failing
On Jan 15, 2008 8:40 PM, Ken Kixmoeller -- reply to [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
On Jan 15, 2008, at 11:08 PM, Andrés Robinet wrote:
I second that, you should base64 encode values before encrypting
and base64
decode them after decrypting to be safe.
Thanks for the idea.
Like this? Fails 500/500 times on my test.
if ($EorD == D) {
$text_out = mdecrypt_generic($cypher,$text);
$text = base64_decode($text);
} else {
$text= base64_encode($text);
$text_out = mcrypt_generic($cypher,$text);
} // endif ($EorD == D)
A quick test looks like this:
1: String: 9334133814260182
-|- Enc: X5Þ(c)·ža`p#È]#c¦±3 ÔýCõÒiÏ~r ¢Tª
-|- Dec:OTMzNDEzMzgxNDI2MDE4Mg== -|- Nope
2: String: 3027022406512648
-|- Enc: j£n,h\m ê´ uKP%¥† ¼D }H‚'f ¢š„
-|- Dec:MzAyNzAyMjQwNjUxMjY0OA== -|- Nope
3: String: 5042504153020331
-|- Enc: 9ÿ• ýŸÝ§¤6Wi+€×Ÿéáon ñº*J 6}Ø+„
-|- Dec:NTA0MjUwNDE1MzAyMDMzMQ== -|- Nope
4: String: 6741156238850410
-|- Enc: · :´[Úq\‹ë‹ 4\Q«ÍŽ5±{º‡µØtþðtN?b
-|- Dec:Njc0MTE1NjIzODg1MDQxMA== -|- Nope
5: String: 0003100244041329
-|- Enc: D¾¤ úV:!Mû 4ƒÜ€àœ‰ŽòÐÐ^ï Hñ-š %z
-|- Dec:MDAwMzEwMDI0NDA0MTMyOQ== -|- Nope
Wrong: 5/5
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
It returns the correct value. If you look at the last example, and run
base64_decode on MDAwMzEwMDI0NDA0MTMyOQ==, you will get
0003100244041329.
-Casey
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Encryption failing
if ($EorD == D) {
$text_out = mdecrypt_generic($cypher,$text);
$text = base64_decode($text);
shouldn't this be base64_decode($text_out) ? :)
} else {
$text= base64_encode($text);
$text_out = mcrypt_generic($cypher,$text);
reverse these... make sure $text is setup right
} // endif ($EorD == D)
if you want to use this via cookies, GET, POST, etc. i would
encrypt
base64 encode
to decrypt:
string replace to +
base64 decode
then decrypt
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Encryption failing
-Original Message-
From: mike [mailto:[EMAIL PROTECTED]
Sent: Wednesday, January 16, 2008 1:49 AM
To: Ken Kixmoeller -- reply to [EMAIL PROTECTED]
Cc: php-general@lists.php.net
Subject: Re: [PHP] Encryption failing
if ($EorD == D) {
$text_out = mdecrypt_generic($cypher,$text);
$text = base64_decode($text);
shouldn't this be base64_decode($text_out) ? :)
} else {
$text= base64_encode($text);
$text_out = mcrypt_generic($cypher,$text);
reverse these... make sure $text is setup right
} // endif ($EorD == D)
if you want to use this via cookies, GET, POST, etc. i would
encrypt
base64 encode
to decrypt:
string replace to +
base64 decode
then decrypt
Hi Ken,
Just my 3 cents:
1 - Mike is right about first encrypting and then doing a base64_encode (then
saving results to DB, cookies, etc). I don't know why replacing to + for
decrypting, though.
2 - Mike is also right about $text = base64_decode($text) which should be $text
= base64_decode($text_out) I think.
3 - You are trimming the results on return, according to one post in the manual
notes this will remove null padding on the decrypted string. This is desired,
most of the time, but if the original (cleartext message) string ended in nulls
you will get a difference and that may be the cause of the errors you are
getting.
if ($EorD == D) {
// Get the original encrypted string
$text = base64_decode($text);
// Decrypt, you will get null padding
$text = mdecrypt_generic($cypher, $text);
// Restore the original text, you must keep the original text length stored
somewhere
$text_out = substr($text, 0, $text_length);
} else {
$text_length = strlen($text);
// base64 encode encrypted string, to avoid headaches with strange
characters in db, variables, etc
$text_out = base64_encode(mcrypt_generic($cypher, $text));
}
// Do not trim results if the clear text message ends with nulls
I'll have to work on something similar very soon, so I might have my own
headaches later. If you have success (or even more trouble) any feedback would
be much appreciated.
Regards,
Rob
Andrés Robinet | Lead Developer | BESTPLACE CORPORATION
5100 Bayview Drive 206, Royal Lauderdale Landings, Fort Lauderdale, FL 33308 |
TEL 954-607-4207 | FAX 954-337-2695
Email: [EMAIL PROTECTED] | MSN Chat: [EMAIL PROTECTED] | SKYPE: bestplace |
Web: http://www.bestplace.biz | Web: http://www.seo-diy.com
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Encryption failing
On 1/15/08, Andrés Robinet [EMAIL PROTECTED] wrote: 1 - Mike is right about first encrypting and then doing a base64_encode (then saving results to DB, cookies, etc). I don't know why replacing to + for decrypting, though. we have an application which sets an encrypted cookie in .NET, and base64 encodes it. for some reason, PHP was choking on spaces, but + worked like a charm. not sure if it's something odd in the URL encoding during transit or what... but it works like a charm. I have on my todo list to post the code samples both from .NET side and PHP side to help other people, but I haven't got around to it (not to mention I have to take out some custom code specific to my company's implementation)
Re: [PHP] Encryption Advice
On Sat, May 20, 2006 10:35 am, Lawrence Kennon wrote: --- Rory Browne [EMAIL PROTECTED] wrote: but does support Cardservice International. These guys give you a PHP library that you http://php.net/include which then provides functions you can call which you pass in the CC# and they give you back a success/failure code and a Transaction number. You never have to visit their URL or anything like that in the process. Or, even easier, install something like osCommerce or ZenCart of any of the zillion shopping carts and they'll have a plug-in for Cardservice International, and you don't have to do much more than install and configure the damn thing. -- Like Music? http://l-i-e.com/artists.htm -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Encryption Advice
--- Rory Browne [EMAIL PROTECTED] wrote: It's better if, when it comes to time to checkout, you redirect your client to your Payment Service Providers (PSP's) website, your PSP processes the payment, and redirects the client back to your site. The PSP would then contact you directly to confirm the payment. That way there is no CC info on your server for you to protect. I really appreciate all the advice people have given. So the following questions are designed to try to fully understand the scenario and what the customer sees from their viewpoint. The site that I am trying to fix is absolutely awful right now. It is certainly not a high volume site, although I do think if properly designed it could do a lot more business than it does. It is the site of a self-published author and I think most people who buy his books go to Amazon to buy them because the shopping cart is so bad (he did it himself years ago, and he is not any kind of web designer or programmer). The site uses the Hassan Shopping Cart which is a Perl script. Looking at the script it appears that it can support some sort of credit card authorization. But the way he has it set up now it just writes each order to a plain text file in a secure subdirectory (obviously a very bad idea) and sends him an email that tells him he has an order on the site to process. His hosting site is discontinuing support for the Hassan Shopping Cart, but does support Cardservice International. So let's say that I want to integrate a shopping cart with a PSP, right up to the moment they get to the checkout, they see my client's URL. They hit the Checkout button and then they will see the URL of the PSP? Then once they place the order then they are redirected back to my client's site and see that URL again? Is that an accurate description of how it works? Do you normally have control over the look and feel of how the checkout looks on the PSP site? Excuse me if these are really basic questions, but I haven't done this before. :) Thanks again, Lawrence Kennon __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Encryption Advice
snip So let's say that I want to integrate a shopping cart with a PSP, right up to the moment they get to the checkout, they see my client's URL. They hit the Checkout button and then they will see the URL of the PSP? Then once they place the order then they are redirected back to my client's site and see that URL again? Is that an accurate description of how it works? Do you normally have control over the look and feel of how the checkout looks on the PSP site? /snip Hi Lawrence, The way you explain it is the way that most of the Payment Service providers seem to work. However - depending on the PSP you use will depend on how much of the look and feel you can change. PayPal for example only allows very basic styling, whereas something like WorldPay (not sure if they are UK only) allows you to create templates, so other than the URL the change is seamless. The PSP will send you an email with the order details, and additionally most can post back to a script on your server with the details of the transaction - i.e. did it work? What was the total amount/currency? Etc. You can then use this to validate it's the correct transaction and send your own email/receipt/picking list accordingly. I've worked on a couple of these so if I can be of any help give me a shout. Cheers, Kev -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Encryption Advice
On 5/19/06, Lawrence Kennon [EMAIL PROTECTED] wrote: For an ecommerce site where sensitive data is stored either in files, or in a database, have you used some form of encryption to protect your customer's data? I have a client who currently uses a Perl scripted shopping cart that stores orders (including credit card numbers) in plain text files on a shared server. The security of these files depends purely on the user/file system security measures enforced by the hosting company (which I think is a reasonably good company, but still I don't see it as being sufficiently secure). I am going to rewrite the shopping cart using PHP and was looking into ways to protect the data. Using GNU Privacy Guard (gpg) seemed like the ideal method because I could store the client's public key on the server to encrypt orders and the customer could then download the encrypted files and decrypt them on his PC with his private key (the client manually submits orders through his store front merchant account). I know this is a somewhat archaic procedure but it works sufficiently well for this client. However the hosting company won't support gpg so that leaves me with PHP mcrypt functions which I think would work very well, except for on thing - how to protect the secret key which now has to be on the server? Any ideas/suggestions/experience along that line? Thanks in advance, Lawrence Kennon Lawrence, from the very start, if you're on a shared-server, security is going to be compromised to a large degree. Hopefully your server at least uses suexec or suphp to prevent other people's scripts reading your data. If not, i'd say look for a new host immediately. As for your private key. Step 1 is to definitely keep it outside your doc_root, Step 2 is to give it really restrictive permissions like 400 or 600. I'm not entirely sure how much you can really do above that on a shared server. If you can convince your clients that security is a top-priority on this project, talk about getting a dedicated box so that your first-level of defense is simply nobody else is on the box, then you can worry a little bit less about your private key being stolen. -- Scott Hurring [scott dot hurring dot lists at gmail dot com] http://hurring.com/
RE: [PHP] Encryption Advice
For an ecommerce site where sensitive data is stored either in files, or in a database, have you used some form of encryption to protect your customer's data? I have a client who currently uses a Perl scripted shopping cart that stores orders (including credit card numbers) in plain text files on a shared server. I assume you want to be able to unencrypt the credit card number for later use, so a 1 way encryption method will not suffice. In that case, I don't know of a way to securly store this data in the environment you describe. If someone gained access to you data, they would also likely have access to your code and could therefore figure out how to unencrypt it. That said, my first piece of advice: Never, ever store credit card numbers. You are opening yourself up to a huge world of hurt by doing so. Unless you can come up with a reason (you probably can't) that you absolutely MUST store credit card numbers on a shared server, don't do it. The security of these files depends purely on the user/file system security measures enforced by the hosting company (which I think is a reasonably good company, but still I don't see it as being sufficiently secure). You are willing to risk bazillion dollar lawsuits on the sufficiently secure file permissions of a reasonably good company? I would suggest, at minimum, getting a dedicated box with a well-known hosting company if you are going to store credit card numbers. At least then, you can enforce you own security policies, and be reasonably sure you are the only one digging around on the box. I am going to rewrite the shopping cart using PHP and was looking into ways to protect the data. Using GNU Privacy Guard (gpg) seemed like the ideal method because I could store the client's public key on the server to encrypt orders and the customer could then download the encrypted files and decrypt them on his PC with his private key (the client manually submits orders through his store front merchant account). I know this is a somewhat archaic procedure but it works sufficiently well for this client. If you are going to rewrite the shopping cart application, why not look into some ready-made ones. http://www.oscommerce.com , a complete, free online store, comes to mind immediately. There are many others. Search the archives of this list if you're interested. Why reinvent the wheel? :) However the hosting company won't support gpg so that leaves me with PHP mcrypt functions which I think would work very well, except for on thing - how to protect the secret key which now has to be on the server? On a shared server, you can't really protect it, but you can take some steps to make it as difficult to get as possible. Storing it outside of webroot and giving it restrictive permissions would be good first steps. You don't really go into much detail about your application. But, if you search the archives of this list for 'credit card', you will find some really compelling reasons NOT to ever store credit card numbers. If the reason you are doing so is purely for customer convienience, you should probably reevaluate that position. JM -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Encryption Advice
Re: Encryption Advice First off, thanks to the folks who replied with advice. I am mulling over your advice (and I greatly appreciate it!). I have been doing PHP programming for a couple years, including secure sites, but this is my first ecommerce venture, so I am trying to learn as much as I can. Also it is for a friend and I figure the learning is my payment. :) In regards to GNU Privacy Guard (gpg), I did actually manage to get that to work in the hosting environment (without the help of the hosting support folks! :). I use a directive to tell gpg to not warn me about using insecure memory but since no private keys reside on this host I think I can safely ignore that (they can't steal what is not there). The real difficulty is that the httpd process runs as an id different than my logon account and I have no shell access. What I did to get around that was to create a subdirectory .gnupg from my html root and ftp'd my pubring.gpg (public key ring) and trustdb.gpg (trust database) into that subdirectory. I secured that wide open (after all, it is a _public_ keyring) cause otherwise gpg will fail. Then I coded the php program to send a command like this using shell_exec: /usr/bin/gpg -a -e -r 'mykeyname' --no-default-keyring --keyring /home/users/web/myhome/.gnupg/pubring.gpg --no-secmem-warning /home/users/web/myhome/ayres In the above the last file ayres is the file to encode and the result of the above is a file ayres.asc which is encoded and ready to be mailed. I used the --no-default-keyring and --keyring to point gpg to the keyrings I ftp'd up to the .gnupg subdirectory. Anyway that worked, and on downloading the encoded file I could decode it with the secret key. Don't know if I will use this approach yet, but it was fun to figure out that it could be done! :) Thanks to all who gave advice! Again, I will give some thought to that, and I very much appreciate advice from people who have been there, done that! Lawrence Kennon __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Encryption Advice
Lawrence Kennon wrote: I use a directive to tell gpg to not warn me about using insecure memory but since no private keys reside on this host I think I can safely ignore that (they can't steal what is not there). But your unencrypted data is there, so someone could possibly snoop that from the insecure memory. Gr, Koen -- K.F.J. Martens, Sonologic, http://www.sonologic.nl/ Networking, hosting, embedded systems, unix, artificial intelligence. Public PGP key: http://www.metro.cx/pubkey-gmc.asc Wondering about the funny attachment your mail program can't read? Visit http://www.openpgp.org/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Encryption Advice
--- Koen Martens [EMAIL PROTECTED] wrote: But your unencrypted data is there, so someone could possibly snoop that from the insecure memory. This is true. I am going to ask the hosting company to setuid gpg as root. That should solve one problem (from gpg docs): This is necessary to lock memory pages. Locking memory pages prevents the operating system from writing them to disk and thereby keeping your secret keys really secret. But just out of curiousity, let's assume you are running a shopping cart which takes credit cards and passes them on to whomever approves them and you don't _ever_ write this info to files. Aren't you also vulnerable to someone being able to snoop memory on your process for sensitive information? I mean at some point some program on the server has to take the customer's credit card, and that info is in memory somewhere until you get the approval. Isn't that true? Thanks!, Lawrence Kennon __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Encryption Advice
--- Koen Martens [EMAIL PROTECTED] wrote: But your unencrypted data is there, so someone could possibly snoop that from the insecure memory. This is true. I am going to ask the hosting company to setuid gpg as root. That should solve one problem (from gpg docs): This is necessary to lock memory pages. Locking memory pages prevents the operating system from writing them to disk and thereby keeping your secret keys really secret. But just out of curiousity, let's assume you are running a shopping cart which takes credit cards and passes them on to whomever approves them and you don't _ever_ write this info to files. Aren't you also vulnerable to someone being able to snoop memory on your process for sensitive information? I mean at some point some program on the server has to take the customer's credit card, and that info is in memory somewhere until you get the approval. Isn't that true? Im my case, I use a third party service that handles credit card payments. I take the order, and pass the order amount to the credit card processing service. THEY take the credit card info into THEIR system, process the payment, then send the customer back to my site. I never take credit card info. So, if somebody steals my customers identity, I am absolved of any responsibility. JM -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Encryption Advice
On Fri, May 19, 2006 8:54 am, Lawrence Kennon wrote: For an ecommerce site where sensitive data is stored either in files, or in a database, have you used some form of encryption to protect your customer's data? I have a client who currently uses a Perl scripted shopping cart that stores orders (including credit card numbers) in plain text files on a shared server. The security of these files depends purely on the user/file system security measures enforced by the hosting company (which I think is a reasonably good company, but still I don't see it as being sufficiently secure). DO NOT STORE CREDIT CARD NUMBERS!!! Period!!! If your PHP script can access them, then they are too accessible to the Bad Guys. It's that simple. I am going to rewrite the shopping cart using PHP and was looking into ways to protect the data. Using GNU Privacy Guard (gpg) seemed like the ideal method because I could store the client's public key on the server to encrypt orders and the customer could then download the encrypted files and decrypt them on his PC with his private key (the client manually submits orders through his store front merchant account). I know this is a somewhat archaic procedure but it works sufficiently well for this client. Just get a friggin' online merchant account, and process the orders in realtime. It's just not that expensive, and will save your client HUGE MONSTROUS amounts of risk. You can set up a recurring charge if you think you need the CC# for that -- and then you get a Tx # from the merch and you do NOT need the CC#. However the hosting company won't support gpg so that leaves me with PHP mcrypt functions which I think would work very well, except for on thing - how to protect the secret key which now has to be on the server? It does? Look, if you absolutely insist doing this the wrong way, AT LEAST make the client upload the key for decrypting and then ERASE the key immediately -- Or better, make him paste it into a big ol' textbox on an https server, and never have it hit the hard drive at all. Any ideas/suggestions/experience along that line? Years ago, I was gonna do what you propose, because my client was too cheap to get a cert and pay the online merch fees. Thank GOD people on this list stopped me. Remember that game hot potato as a kid? CC#s are hot potatos. Get it, process it, nuke it. Fast! -- Like Music? http://l-i-e.com/artists.htm -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Encryption Advice
On Fri, May 19, 2006 1:36 pm, Lawrence Kennon wrote: In regards to GNU Privacy Guard (gpg), I did actually manage to get that to work in the hosting environment (without the help of the hosting support folks! :). I use a directive to tell gpg to not warn me about using insecure memory but since no private keys reside on this host I think I can safely ignore that (they can't steal what is not there). I think the concern here is that the CC#s in *RAM* are susceptible to other users' snooping them. Your data will be in RAM, and you ARE at risk. -- Like Music? http://l-i-e.com/artists.htm -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Encryption Advice
On Fri, May 19, 2006 3:00 pm, Lawrence Kennon wrote: But just out of curiousity, let's assume you are running a shopping cart which takes credit cards and passes them on to whomever approves them and you don't _ever_ write this info to files. Aren't you also vulnerable to someone being able to snoop memory on your process for sensitive information? I mean at some point some program on the server has to take the customer's credit card, and that info is in memory somewhere until you get the approval. Isn't that true? Yes, and it's worse than that. See, if your server gets busy, then those chunks of RAM *will* get paged out to hard drive. And, in theory, users can read that hard drive data not only during the transaction, but long after, until RAM has a page-fault again and wipes it out. So now you've got *TWO* potential holes in your armor. Throw your gpg into the mix, and you've got even more, including: #1. gpg insecure RAM, unless your host change bit for you #2. The data you pass from PHP to gpg through exec is visible to a 'ps' command, if it's timed right, or run often enough, fast enough, to catch it. A quick hack shell script will pretty much catch ALL your CC#s as long as it runs #3. gpg itself may get page-faulted to disk (this may be a duplicate of #1 -- I'm NOT an expert) Bottom line is, as a beginner in this realm, you REALLY should not be trying to do what you are trying to do. You NEED to go to your client and explain the following facts: *IF* their data is every compromised, they are required BY LAW to contact EVERY customer and tell them: Sorry, we just gave away your credit card number to some crooks. Have a nice day. Then describe all the ways (above) that the data is at risk. PLUS, let's look at the store-front end of things. Is the PC locked in a secure location? Or is it just in some office somewhere? How hard would it be for a Bad Guy to get ahold of the PC long enough to hack it to catch keystrokes and snag the private key? Is it behind a firewall? With up-to-date virus-protection? And it's not used for normal web-surfing, right? Cuz, right there, you're just BEGGING some Bad Guy to install mal-ware that will snoop on your private key. Are there any employees who have access to this PC? What sort of background checks have you run on every employee? Do you REALLY want to run the risk of having to DESTROY your reputation with all your customers? -- Like Music? http://l-i-e.com/artists.htm -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Encryption Advice
snip lots of good stuff Are there any employees who have access to this PC? What sort of background checks have you run on every employee? Do you REALLY want to run the risk of having to DESTROY your reputation with all your customers? /snip Not only all that, but suppose one of your customers has his CC info stolen somewhere else, not even on your site. He reports it to the CC company, and they investigate. They're going to ask him where he used his card online. Your site pops up. The CC company contacts you and asks you to describe what you do to protect their customer's CC numbers. You say 'I wrote an encryption routine that I think is pretty good...' :-/ So, even if your site is bulletproof, you are going to have to be ready to back up your claim that the data is safe. The first question an investigator is going to ask is Where is the data stored?. Your answer? A shared server at some hosting company. :-/ The good news is, there is no reason to handle credit cards in an online store. There are tons of third party processors that will take on all these risks for you. JM -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Encryption Advice
DO NOT STORE CREDIT CARD NUMBERS!!! Period!!! If your PHP script can access them, then they are too accessible to the Bad Guys. Ditto Even if nothing else, someone could modify your code to email them the CC Numbers. It's better if, when it comes to time to checkout, you redirect your client to your Payment Service Providers (PSP's) website, your PSP processes the payment, and redirects the client back to your site. The PSP would then contact you directly to confirm the payment. That way there is no CC info on your server for you to protect. Unless you are a computer security professional and _REALLY_ know what you're doing.
RE: [PHP] encryption needed?
If you've set things up so that the id is available client-side, then there's no point in encrypting the id (by any encryption methods). If the id is stored in the client browser, then you'd better make sure it's linked to public data. [Original Message] From: klaus [EMAIL PROTECTED] To: [EMAIL PROTECTED] Date: 07/13/2004 3:17:54 PM Subject: [PHP] encryption needed? Hi all, I am to set up a service where users can view news of companies. To identify the company selected an easy way is to use the company-id. The id is not displayed but stored in the client browser as JS-variable. Question: Is it ok to use the company-id or do I have to encrypt the id using mcrypt (takes some time)? Thanks in advance Klaus -- 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] encryption needed?
I wouldn't encrypt the ID, but I can't help wonder why you don't want people knowing the company's ID. They can get access to it if you're storing it client-side. This is like using a single script to view documents where you provide the ID of the document to display. http://localhost/view.php?ID=33 You end up needing a different way to reference which document should be displayed, if you don't want people to know the ID. In this case, I'd end up specifying the name of the document to display. http://localhost/view.php?Name=The%20Pizza%20Caper As you can see, you end up having to deal with spaces and other special characters in the name... Basically, I'd just use the ID and not worry about encrypting it, unless you have a good reason to do so. -Ed -Original Message- Is it ok to use the company-id or do I have to encrypt the id using mcrypt (takes some time)? -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Encryption Question SOLVED
[snip]
I am encrypting some data on one server and now I am attempting to decrypt on another
server using mcrypt_encrypt and mycrypt_decrypt (using same key and initialzation
vector). It is almost working but I seem to still have a little problem, that data is
missing the last character which still seems to be encrypted. I am putting the data in
the database with addslashes, and retrieving with stripslashes, but I get things like
this;
45221141¤Þ,]¹9Ñ
7775ÿåZ|z
while($arrEncInfo = mysql_fetch_array($dbGetSub)){
$stripDataA = stripslashes($arrEncInfo['dataA']);
$stripIV = stripslashes($arrEncInfo['iv']);
$dataA = mcrypt_decrypt($encAlg, $encKey, $stripDataA, $encMode, $stripIV);
echo $dataA . \n;
}
Has anyone seen this? Could there be a difference between the PHP installs? Both are
version 4.3.7.
[/snip]
I found the problem on the field in question. I had left the column in the database
the same length as it was prior to encrypting the data. This, as it turns out, is a
BAD THING [tm]. Make sure that database columns are large enough to hold the whole of
the encrypted data.
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Encryption question
I wouldn't use crypt, instead use one of the proven more secure hashes like md5 or sha1. For password hashing I'd use md5 (PHP 3 and 4) if you want broad support or sha1 for a little more security (sha1 hasn't been in PHP as long (only since 4.3.0) so you will lose some compatability, Ryan Thompson wrote: I know this is an opinion thing but what's the best functions or function set for password encryption? Currently my project uses md5 but I thinks it's more for checksums isn't it? Also, is mcrypt used for passwords? I looks like it's a two-way encryption. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Encryption question
Sorry. Just stumbled on crypt() On Friday 10 October 2003 22:31, Ryan Thompson wrote: I know this is an opinion thing but what's the best functions or function set for password encryption? Currently my project uses md5 but I thinks it's more for checksums isn't it? Also, is mcrypt used for passwords? I looks like it's a two-way encryption. -- Ryan Thompson [EMAIL PROTECTED] http://osgw.sourceforge.net == A computer scientist is someone who fixes things that aren't broken --Unknown -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Encryption question
On Fri, 2003-10-10 at 20:31, Ryan Thompson wrote: I know this is an opinion thing but what's the best functions or function set for password encryption? Currently my project uses md5 but I thinks it's more for checksums isn't it? Also, is mcrypt used for passwords? I looks like it's a two-way encryption. md5 is a one-way hash function. It is great for passwords. (I'm not sure if that technically qualifies as encryption because it is nearly impossible to decrypt..hmm) Anyway, I would recommend using it. - Brad -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Encryption question
I think it all falls under the cryptography category, but you're right - it doesn't fall into the encryption/decryption scheme since it is only one-way. -M -Original Message- From: Brad Pauly [mailto:[EMAIL PROTECTED] Sent: Friday, October 10, 2003 10:43 PM To: php-gen Subject: Re: [PHP] Encryption question md5 is a one-way hash function. It is great for passwords. (I'm not sure if that technically qualifies as encryption because it is nearly impossible to decrypt..hmm) Anyway, I would recommend using it. - Brad -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Encryption using MMCrypt - whats the point?
Not a good idea, you might look at some form of public key encryption where you encrypt the credit card information with the public key and the merchant decrypts it with their private key that is not on the server. You generally do not want to store the information encrypted with mcrypt because in order for your application to encrypt it it must know the key and the IV, in order for an attacker to decypt it all they need is the IV and key as well. There is a PHP module named GPG Extension available at http://www.sourceforge.net/projects/gpgext/, it uses the gpg made easy library to enable PHP to do public key encryption without launching command line programs (also insecure). Basically look on google for information on storing credit card numbers, it is not easy to do this securely and generally good advice is not to do it. If you have your merchants going over an SSL connection (which you should) you can write your own PHP session handler and use mcrypt to encrypt the session information with a random key generated by your script, since it is passed over SSL it is encrypted in transit, then decrypt the session information and load it. Encrypting your sessions opens the possibility to store more sensitive information inside them. I still do not recommend storing credit card information even with these measures, it exposes you for liability should something bad happen. Take a look at authorize.net or verisign's credit card processing services, or find out if other processing companies have the capability to store credit card information. Jason On Thu, 2003-01-30 at 07:30, Mike Morton wrote: I want to use the mcrypt functions to encrypt credit card numbers for storage in a mysql database, which mycrypt does admirably: $key = this is a secret key; $input = Let us meet at 9 o'clock at the secret place.; $iv = mcrypt_create_iv (mcrypt_get_iv_size (MCRYPT_RIJNDAEL_256, MCRYPT_MODE_CBC), MCRYPT_RAND); $encrypted_data = base64_encode(@mcrypt_encrypt (MCRYPT_RIJNDAEL_256 , $key, $input, MCRYPT_MODE_CBC,$iv)); The trouble is - the key and the IV. Both of these have to be available in the merchants administration for retrieval of the credit card, thus need to be stored somewhere - most likely on the server or in a database. Here is the problem - if someone gets to the database and retrieves the encrypted credit card, the chances are that they are able to also retrieve the script that did the encryption, thus find out where the key and IV are stored, making it simple to decrypt the credit card for them. The only solution that I can see is to use an asymetric encryption and have the merchant enter the decryption key at the time of credit card retrieval - but that is unrealistic for a User Interface point of view. So - the only other thing that I can see to do is have a compiled program, bound to the server, that has the key compiled into the program. I am not a C programmer - so this is also not exactly possible. Does anyone else have any answers or has anyone else run into this? Is this just a general problem with doing encryption through PHP as opposed to a compiled binary? Can anyone suggest a solution to this problem? Thanks :) -- Cheers Mike Morton * * E-Commerce for Small Business * http://www.dxstorm.com * * DXSTORM.COM * 824 Winston Churchill Blvd, * Oakville, ON, CA L6J 7X2 * Tel: 905-842-8262 * Fax: 905-842-3255 * Toll Free: 1-877-397-8676 * Indeed, it would not be an exaggeration to describe the history of the computer industry for the past decade as a massive effort to keep up with Apple. - Byte Magazine Given infinite time, 100 monkeys could type out the complete works of Shakespeare. Win 98 source code? Eight monkeys, five minutes. -- NullGrey -- 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] Encryption using MMCrypt - whats the point?
Could you use the Zend Encoder to encrypt the PHP script? http://www.zend.com/store/products/zend-safeguard-suite.php -- Lowell Allen From: Mike Morton [EMAIL PROTECTED] Date: Thu, 30 Jan 2003 09:30:36 -0500 To: [EMAIL PROTECTED] Subject: [PHP] Encryption using MMCrypt - whats the point? I want to use the mcrypt functions to encrypt credit card numbers for storage in a mysql database, which mycrypt does admirably: $key = this is a secret key; $input = Let us meet at 9 o'clock at the secret place.; $iv = mcrypt_create_iv (mcrypt_get_iv_size (MCRYPT_RIJNDAEL_256, MCRYPT_MODE_CBC), MCRYPT_RAND); $encrypted_data = base64_encode(@mcrypt_encrypt (MCRYPT_RIJNDAEL_256 , $key, $input, MCRYPT_MODE_CBC,$iv)); The trouble is - the key and the IV. Both of these have to be available in the merchants administration for retrieval of the credit card, thus need to be stored somewhere - most likely on the server or in a database. Here is the problem - if someone gets to the database and retrieves the encrypted credit card, the chances are that they are able to also retrieve the script that did the encryption, thus find out where the key and IV are stored, making it simple to decrypt the credit card for them. The only solution that I can see is to use an asymetric encryption and have the merchant enter the decryption key at the time of credit card retrieval - but that is unrealistic for a User Interface point of view. So - the only other thing that I can see to do is have a compiled program, bound to the server, that has the key compiled into the program. I am not a C programmer - so this is also not exactly possible. Does anyone else have any answers or has anyone else run into this? Is this just a general problem with doing encryption through PHP as opposed to a compiled binary? Can anyone suggest a solution to this problem? Thanks :) -- Cheers Mike Morton * * E-Commerce for Small Business * http://www.dxstorm.com * * DXSTORM.COM * 824 Winston Churchill Blvd, * Oakville, ON, CA L6J 7X2 * Tel: 905-842-8262 * Fax: 905-842-3255 * Toll Free: 1-877-397-8676 * Indeed, it would not be an exaggeration to describe the history of the computer industry for the past decade as a massive effort to keep up with Apple. - Byte Magazine Given infinite time, 100 monkeys could type out the complete works of Shakespeare. Win 98 source code? Eight monkeys, five minutes. -- NullGrey -- 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] Encryption using MMCrypt - whats the point?
http://www.ioncube.com/ Encrypt PHP scripts (there pretty cheap to). On Thu, 2003-01-30 at 09:30, Mike Morton wrote: I want to use the mcrypt functions to encrypt credit card numbers for storage in a mysql database, which mycrypt does admirably: $key = this is a secret key; $input = Let us meet at 9 o'clock at the secret place.; $iv = mcrypt_create_iv (mcrypt_get_iv_size (MCRYPT_RIJNDAEL_256, MCRYPT_MODE_CBC), MCRYPT_RAND); $encrypted_data = base64_encode(@mcrypt_encrypt (MCRYPT_RIJNDAEL_256 , $key, $input, MCRYPT_MODE_CBC,$iv)); The trouble is - the key and the IV. Both of these have to be available in the merchants administration for retrieval of the credit card, thus need to be stored somewhere - most likely on the server or in a database. Here is the problem - if someone gets to the database and retrieves the encrypted credit card, the chances are that they are able to also retrieve the script that did the encryption, thus find out where the key and IV are stored, making it simple to decrypt the credit card for them. The only solution that I can see is to use an asymetric encryption and have the merchant enter the decryption key at the time of credit card retrieval - but that is unrealistic for a User Interface point of view. So - the only other thing that I can see to do is have a compiled program, bound to the server, that has the key compiled into the program. I am not a C programmer - so this is also not exactly possible. Does anyone else have any answers or has anyone else run into this? Is this just a general problem with doing encryption through PHP as opposed to a compiled binary? Can anyone suggest a solution to this problem? Thanks :) -- Cheers Mike Morton * * E-Commerce for Small Business * http://www.dxstorm.com * * DXSTORM.COM * 824 Winston Churchill Blvd, * Oakville, ON, CA L6J 7X2 * Tel: 905-842-8262 * Fax: 905-842-3255 * Toll Free: 1-877-397-8676 * Indeed, it would not be an exaggeration to describe the history of the computer industry for the past decade as a massive effort to keep up with Apple. - Byte Magazine Given infinite time, 100 monkeys could type out the complete works of Shakespeare. Win 98 source code? Eight monkeys, five minutes. -- NullGrey -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- Adam Voigt ([EMAIL PROTECTED]) The Cryptocomm Group My GPG Key: http://64.238.252.49:8080/adam_at_cryptocomm.asc signature.asc Description: This is a digitally signed message part
Re: [PHP] Encryption using MMCrypt - whats the point?
Adam/Lowell: Thanks for the suggestions but like all clients they want maximum function for minimum $$ - encoders are therefore not a possibility (but I will keep that in mind for future apps :)) Thanks. On 1/30/03 9:55 AM, Adam Voigt [EMAIL PROTECTED] wrote: http://www.ioncube.com/ Encrypt PHP scripts (there pretty cheap to). On Thu, 2003-01-30 at 09:30, Mike Morton wrote: I want to use the mcrypt functions to encrypt credit card numbers for storage in a mysql database, which mycrypt does admirably: $key = this is a secret key; $input = Let us meet at 9 o'clock at the secret place.; $iv = mcrypt_create_iv (mcrypt_get_iv_size (MCRYPT_RIJNDAEL_256, MCRYPT_MODE_CBC), MCRYPT_RAND); $encrypted_data = base64_encode(@mcrypt_encrypt (MCRYPT_RIJNDAEL_256 , $key, $input, MCRYPT_MODE_CBC,$iv)); The trouble is - the key and the IV. Both of these have to be available in the merchants administration for retrieval of the credit card, thus need to be stored somewhere - most likely on the server or in a database. Here is the problem - if someone gets to the database and retrieves the encrypted credit card, the chances are that they are able to also retrieve the script that did the encryption, thus find out where the key and IV are stored, making it simple to decrypt the credit card for them. The only solution that I can see is to use an asymetric encryption and have the merchant enter the decryption key at the time of credit card retrieval - but that is unrealistic for a User Interface point of view. So - the only other thing that I can see to do is have a compiled program, bound to the server, that has the key compiled into the program. I am not a C programmer - so this is also not exactly possible. Does anyone else have any answers or has anyone else run into this? Is this just a general problem with doing encryption through PHP as opposed to a compiled binary? Can anyone suggest a solution to this problem? Thanks :) -- Cheers Mike Morton * * E-Commerce for Small Business * http://www.dxstorm.com * * DXSTORM.COM * 824 Winston Churchill Blvd, * Oakville, ON, CA L6J 7X2 * Tel: 905-842-8262 * Fax: 905-842-3255 * Toll Free: 1-877-397-8676 * Indeed, it would not be an exaggeration to describe the history of the computer industry for the past decade as a massive effort to keep up with Apple. - Byte Magazine Given infinite time, 100 monkeys could type out the complete works of Shakespeare. Win 98 source code? Eight monkeys, five minutes. -- NullGrey
Re: [PHP] Encryption using MMCrypt - whats the point?
Title: Re: [PHP] Encryption using MMCrypt - whats the point? Granted, the $350 stand-alone encoder is a bit expensive. I'm talking about the online encoder though, you pass your PHP script through the online-control center and it output's the encrypted version, a typical PHP program is $5.00 (yes that's five dollar's), try selecting your code after you register for a free account, it will tell you how much it would cost to encode it. And after it is encoded, the decoder's (the things you put on the server to run the encrypted program's) are 100% free. On Thu, 2003-01-30 at 10:03, Mike Morton wrote: Adam/Lowell: Thanks for the suggestions but like all clients they want maximum function for minimum $$ - encoders are therefore not a possibility (but I will keep that in mind for future apps :)) Thanks. On 1/30/03 9:55 AM, Adam Voigt [EMAIL PROTECTED] wrote: http://www.ioncube.com/ Encrypt PHP scripts (there pretty cheap to). On Thu, 2003-01-30 at 09:30, Mike Morton wrote: I want to use the mcrypt functions to encrypt credit card numbers for storage in a mysql database, which mycrypt does admirably: $key = this is a secret key; $input = Let us meet at 9 o'clock at the secret place.; $iv = mcrypt_create_iv (mcrypt_get_iv_size (MCRYPT_RIJNDAEL_256, MCRYPT_MODE_CBC), MCRYPT_RAND); $encrypted_data = base64_encode(@mcrypt_encrypt (MCRYPT_RIJNDAEL_256 , $key, $input, MCRYPT_MODE_CBC,$iv)); The trouble is - the key and the IV. Both of these have to be available in the merchants administration for retrieval of the credit card, thus need to be stored somewhere - most likely on the server or in a database. Here is the problem - if someone gets to the database and retrieves the encrypted credit card, the chances are that they are able to also retrieve the script that did the encryption, thus find out where the key and IV are stored, making it simple to decrypt the credit card for them. The only solution that I can see is to use an asymetric encryption and have the merchant enter the decryption key at the time of credit card retrieval - but that is unrealistic for a User Interface point of view. So - the only other thing that I can see to do is have a compiled program, bound to the server, that has the key compiled into the program. I am not a C programmer - so this is also not exactly possible. Does anyone else have any answers or has anyone else run into this? Is this just a general problem with doing encryption through PHP as opposed to a compiled binary? Can anyone suggest a solution to this problem? Thanks :) -- Cheers Mike Morton * * E-Commerce for Small Business * http://www.dxstorm.com * * DXSTORM.COM * 824 Winston Churchill Blvd, * Oakville, ON, CA L6J 7X2 * Tel: 905-842-8262 * Fax: 905-842-3255 * Toll Free: 1-877-397-8676 * Indeed, it would not be an exaggeration to describe the history of the computer industry for the past decade as a massive effort to keep up with Apple. - Byte Magazine Given infinite time, 100 monkeys could type out the complete works of Shakespeare. Win 98 source code? Eight monkeys, five minutes. -- NullGrey -- Adam Voigt ([EMAIL PROTECTED]) The Cryptocomm Group My GPG Key: http://64.238.252.49:8080/adam_at_cryptocomm.asc signature.asc Description: This is a digitally signed message part
Re: [PHP] Encryption using MMCrypt - whats the point?
Using a PHP encoder or compiling a binary does not make it more secure than storing the IV and encryption key in plain text in a PHP script. The problem is the fact that the encryption cipher requires the same key for encryption and decryption, this is not a problem in many encryption cases but in cases where you want to be able to encrypt but not decrypt the information on the server public key encryption is the better solution, which unfortunately mcrypt does not support. Using a compiled/encoded program is just security through obscurity which is an illusion and definitely not something you want to do with credit card numbers. Jason On Thu, 2003-01-30 at 08:03, Adam Voigt wrote: Granted, the $350 stand-alone encoder is a bit expensive. I'm talking about the online encoder though, you pass your PHP script through the online-control center and it output's the encrypted version, a typical PHP program is $5.00 (yes that's five dollar's), try selecting your code after you register for a free account, it will tell you how much it would cost to encode it. And after it is encoded, the decoder's (the things you put on the server to run the encrypted program's) are 100% free. On Thu, 2003-01-30 at 10:03, Mike Morton wrote: Adam/Lowell: Thanks for the suggestions but like all clients they want maximum function for minimum $$ - encoders are therefore not a possibility (but I will keep that in mind for future apps :)) Thanks. On 1/30/03 9:55 AM, Adam Voigt [EMAIL PROTECTED] wrote: http://www.ioncube.com/ Encrypt PHP scripts (there pretty cheap to). On Thu, 2003-01-30 at 09:30, Mike Morton wrote: I want to use the mcrypt functions to encrypt credit card numbers for storage in a mysql database, which mycrypt does admirably: $key = this is a secret key; $input = Let us meet at 9 o'clock at the secret place.; $iv = mcrypt_create_iv (mcrypt_get_iv_size (MCRYPT_RIJNDAEL_256, MCRYPT_MODE_CBC), MCRYPT_RAND); $encrypted_data = base64_encode(@mcrypt_encrypt (MCRYPT_RIJNDAEL_256 , $key, $input, MCRYPT_MODE_CBC,$iv)); The trouble is - the key and the IV. Both of these have to be available in the merchants administration for retrieval of the credit card, thus need to be stored somewhere - most likely on the server or in a database. Here is the problem - if someone gets to the database and retrieves the encrypted credit card, the chances are that they are able to also retrieve the script that did the encryption, thus find out where the key and IV are stored, making it simple to decrypt the credit card for them. The only solution that I can see is to use an asymetric encryption and have the merchant enter the decryption key at the time of credit card retrieval - but that is unrealistic for a User Interface point of view. So - the only other thing that I can see to do is have a compiled program, bound to the server, that has the key compiled into the program. I am not a C programmer - so this is also not exactly possible. Does anyone else have any answers or has anyone else run into this? Is this just a general problem with doing encryption through PHP as opposed to a compiled binary? Can anyone suggest a solution to this problem? Thanks :) -- Cheers Mike Morton * * E-Commerce for Small Business * http://www.dxstorm.com * * DXSTORM.COM * 824 Winston Churchill Blvd, * Oakville, ON, CA L6J 7X2 * Tel: 905-842-8262 * Fax: 905-842-3255 * Toll Free: 1-877-397-8676 * Indeed, it would not be an exaggeration to describe the history of the computer industry for the past decade as a massive effort to keep up with Apple. - Byte Magazine Given infinite time, 100 monkeys could type out the complete works of Shakespeare. Win 98 source code? Eight monkeys, five minutes. -- NullGrey -- Adam Voigt ([EMAIL PROTECTED]) The Cryptocomm Group My GPG Key: http://64.238.252.49:8080/adam_at_cryptocomm.asc -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Encryption Question
I want to compare a password to a encrypted password stored in my
mySQL
database using password('password'), what's the best way to compare
the
two?
Encrypted the password sent by the user and compare or pull the
password
from the database based on username, decrypt it and then compare?
SELECT 1 FROM table WHERE password_column = PASSWORD('$password') AND
username = '$username'
If a row is returned, the username and password match what's in the
database. $password and $username would come from your form or
whatever...
---John Holmes...
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Encryption Question
Just how are you going to decrypt it? Password encryption is ordinarily
one-way - you have no choice. You have to compare encrypted passwords.
-Original Message-
From: Tom Ray [mailto:[EMAIL PROTECTED]]
SI want to compare a password to a encrypted password stored in my mySQL
database using password('password'), what's the best way to compare the two?
Encrypted the password sent by the user and compare or pull the password
from the database based on username, decrypt it and then compare?
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Encryption of emails.
Actually, there ARE servers at both ends. And the one I am sending to is cut off from the net except for the SMTP mail port so I can do whatever I want to with it. That's an excellent idea! *slaps head* Why didn't I think of that? :) Thanks Justin! Bob - Original Message - From: Justin French [EMAIL PROTECTED] To: Bob Irwin [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Thursday, September 05, 2002 4:00 PM Subject: Re: [PHP] Encryption of emails. Perhaps not EXACTLY what you're after, but I wrote a small, simple function to encrypt a string with a key (i'll skip a long note about keeping the key safe). Then I send an email with the data encrypted, and decrypt it at the other end (me) using a decrypt script located on my local server. It required PHP at both ends, which is a little catch. If I move it into client systems, I'll look at a windows GUI to decrypt. Justin on 05/09/02 3:29 PM, Bob Irwin ([EMAIL PROTECTED]) wrote: Hey guys, Can anyone recommend any PHP functions or plugins that will allow me to send encrypted emails via PHP? Something similar to PGP would be excellent. I have use PGP with a formmail cgi previously, but obviously it'd be easier to have in-PHP support for it. Any suggestions are much appreciated! Best Regards Bob Irwin Server Admin Web Programmer Planet Netcom -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php Scanned by PeNiCillin http://safe-t-net.pnc.com.au/ Scanned by PeNiCillin http://safe-t-net.pnc.com.au/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Encryption of emails.
Perhaps not EXACTLY what you're after, but I wrote a small, simple function to encrypt a string with a key (i'll skip a long note about keeping the key safe). Then I send an email with the data encrypted, and decrypt it at the other end (me) using a decrypt script located on my local server. It required PHP at both ends, which is a little catch. If I move it into client systems, I'll look at a windows GUI to decrypt. Justin on 05/09/02 3:29 PM, Bob Irwin ([EMAIL PROTECTED]) wrote: Hey guys, Can anyone recommend any PHP functions or plugins that will allow me to send encrypted emails via PHP? Something similar to PGP would be excellent. I have use PGP with a formmail cgi previously, but obviously it'd be easier to have in-PHP support for it. Any suggestions are much appreciated! Best Regards Bob Irwin Server Admin Web Programmer Planet Netcom -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Re: PHP encryption
My company is going to be 1. Hosting our code on other people servers 2. selling our programs. We are going to be needing to encrypt the codewhat would you all suggest? How about Zend Encoder...is it any good? (even though its so much $$) Disclosure: I'm a former employee and come with some bias... I think it works pretty nifty myself. Not cheap, no, but it's a very niche market. Note, however, that you *STILL* want a clear license and make sure people know it. There's probably still a free trial download, right? Try it. -- Like Music? http://l-i-e.com/artists.htm -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] encryption and HTTP
The PHPLIB auth class has some code to do this. You might want to look there for ideas. If I recall correctly, they sent a hidden random string along with the form that was different on each request. They then did an md5 hash of the post data concatenated with the random string. Kirk -Original Message- From: Erik Price [mailto:[EMAIL PROTECTED]] Sent: Saturday, February 23, 2002 12:20 PM To: PHP Subject: [PHP] encryption and HTTP Without using SSL or JavaScript, is there any way to make an md5 hash or encrypt a string before sending it out as a POST request? It seems that without encrypting the data before sending it, it can still be intercepted. Once intercepted, it doesn't matter if I use md5() on the $_POST['password'] once it gets to the script, because anyone can submit the same intercepted string to the script via POST and it will be md5()ed when it gets there, thus defeating the purpose. Maybe I haven't quite wrapped my brain around a decent authentication scheme yet. Erik Erik Price Web Developer Temp Media Lab, H.H. Brown [EMAIL PROTECTED] -- 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] encryption
MySQL has a PASSWORD() function which encrypts passwords for you!!! Retrieving the user records using the username and encrypted password as selection criteria will either bring back the appropriate record (ie the log in worked) or no record (ie password/username supplied were incorrect) HTH Richy -Original Message- From: Justin French [SMTP:[EMAIL PROTECTED]] Sent: 06 December 2001 12:33 To: php Subject:[PHP] encryption Hi, Can someone give me a brief over view of how to encrypt a password and store it in a MySQL DB, then be able to validate thier plain text password on login against the encrypted one on the DB? I'm guessing I: 1. encrypt the desired password with some sort of key (eg blahblah) which is hidden in a protected directory 2. write the encrypted password to the database Next time the user logs in: 1. take thier plain-text password they submit to login 2. encrypt it with the same key 3. compare it to the one on the database Or, is there something i'm missing, some sort of gaping big arse security hole, or some set of functions which take care of a heap of this stuff for me? If someone could point me to the right encryption tools / links / tutorials, i'd be gratefull. TIA Justin French -- PHP General 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 General 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] encryption
UPDATE members set passwd=PASSWORD(passwd); select login from members where PASSWORD($form_pass)=passwd; Regards, Adnrey Hristov - Original Message - From: Justin French [EMAIL PROTECTED] To: php [EMAIL PROTECTED] Sent: Thursday, December 06, 2001 2:32 PM Subject: [PHP] encryption Hi, Can someone give me a brief over view of how to encrypt a password and store it in a MySQL DB, then be able to validate thier plain text password on login against the encrypted one on the DB? I'm guessing I: 1. encrypt the desired password with some sort of key (eg blahblah) which is hidden in a protected directory 2. write the encrypted password to the database Next time the user logs in: 1. take thier plain-text password they submit to login 2. encrypt it with the same key 3. compare it to the one on the database Or, is there something i'm missing, some sort of gaping big arse security hole, or some set of functions which take care of a heap of this stuff for me? If someone could point me to the right encryption tools / links / tutorials, i'd be gratefull. TIA Justin French -- PHP General 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 General 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] encryption
* Justin French [EMAIL PROTECTED] [Dec 06. 2001 07:33]: Can someone give me a brief over view of how to encrypt a password and store it in a MySQL DB, then be able to validate thier plain text password on login against the encrypted one on the DB? An alternative is to just store an Md5 of the password and not the actual password. http://www.php.net/md5 -- -Brian Clark -- PHP General 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] encryption
I agree... MD5 is the best way to store passwords... you only store the md5 hash of the actual password, then when the user logins you have to compare the stored hash with the md5 hash of password the user uses to login! cheers, Valter Santos - Original Message - From: Brian Clark [EMAIL PROTECTED] To: PHP is not a drug. [EMAIL PROTECTED] Sent: Thursday, December 06, 2001 2:48 PM Subject: Re: [PHP] encryption * Justin French [EMAIL PROTECTED] [Dec 06. 2001 07:33]: Can someone give me a brief over view of how to encrypt a password and store it in a MySQL DB, then be able to validate thier plain text password on login against the encrypted one on the DB? An alternative is to just store an Md5 of the password and not the actual password. http://www.php.net/md5 -- -Brian Clark -- PHP General 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 General 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] encryption
I don't know if this was mentioned but you can do it all in MySQL with the
password() function.
Ex:
INSERT INTO users (username,password) VALUES ('tyler',PASSWORD('testpass'));
Also:
SELECT * FROM users WHERE username='$username' AND
password=PASSWORD('testpass');
Good luck,
Tyler Longren
- Original Message -
From: Valter Santos [EMAIL PROTECTED]
To: Brian Clark [EMAIL PROTECTED]; PHP is not a drug.
[EMAIL PROTECTED]
Sent: Thursday, December 06, 2001 9:34 AM
Subject: Re: [PHP] encryption
I agree... MD5 is the best way to store passwords...
you only store the md5 hash of the actual password, then when the
user logins you have to compare the stored hash with the md5 hash
of password the user uses to login!
cheers,
Valter Santos
- Original Message -
From: Brian Clark [EMAIL PROTECTED]
To: PHP is not a drug. [EMAIL PROTECTED]
Sent: Thursday, December 06, 2001 2:48 PM
Subject: Re: [PHP] encryption
* Justin French [EMAIL PROTECTED] [Dec 06. 2001 07:33]:
Can someone give me a brief over view of how to encrypt a password and
store it in a MySQL DB, then be able to validate thier plain text
password on login against the encrypted one on the DB?
An alternative is to just store an Md5 of the password and not the
actual password.
http://www.php.net/md5
--
-Brian Clark
--
PHP General 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 General 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 General 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] encryption
How do you get around the Server and client running on different times? I would think that would screw up the system as they would be generating them at different times? Other than that possible problem I like the idea. However, I would like to point out that anything done client-side can not be completely secure as anyone can get your algorithm from the JavaScript. Maybe You could devise some system with keys where the PHP page would write the Javascript Function with a different key based on time or something? That might work. Thoughts? Sheridan - Original Message - From: Francis Fillion [EMAIL PROTECTED] To: Tom Malone [EMAIL PROTECTED] Cc: PHP Users [EMAIL PROTECTED] Sent: Thursday, July 19, 2001 5:14 PM Subject: Re: [PHP] encryption One of my friends has a rsa key somethings, what it does is that at every few minutes it generate a random number so for login on his server he need this random key and his password to get in, the server generate the same key as his rsa key and has his password. SO the best things to do will be to make two program that use something to generate a random alphanumeric something on the server side and on your client side so when you connect to the server both have you has this key + your password, if it's OK it start a PHP session. And the key should be regenerated once you have login. SO even if somebody extract the clear text key+password from your connection he can't connect because this key+password is already passdue, the only possible attack then is to find the algorithm that you use+password, by changing your algorithm once in a while you can really limit this, they other attack could be a man in the middle attack, that could hurt. Good idea, I have to use this (let's put-it down on my project list,...), I could even put the generate stuff on my pda, I could login from anywhere... ;) Tom Malone wrote: I guess I should clarify - I'm just making a login for myself for the admin section of my website, so I only need to be able to protect my own password. I'm not sure if that information if helpful at all, but I haven't been able to figure out how to do it. Tom -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Thursday, July 19, 2001 3:21 PM To: Sheridan Saint-Michel Cc: php-general Subject: Re: [PHP] encryption Ahh, well then, another solution could be to use SSL, depends on your application weather you can get away with using an unsigned certificate (free) or weather you will need to pay a company like verisign to prove your identity. With an unsigned certificate the browser will warn the user that the certificate says it's you, but it's not proven by a CA so it might not be you. The JavaScript MD5 tenique is an interesting way of doing it, but i don't think it's any more secure. If a hacker sniffs the md5 hash how is that any diffrent than him sniffing a plain text password? You're comparing hashes, so as long as he has the hash he's in. On Thu, Jul 19, 2001 at 01:58:43PM -0500, Sheridan Saint-Michel wrote: The problem he is addressing is that the password is sent plaintext to the server before it ever gets to MySQL. I would suggest using a JavaScript program like this http://pajhome.org.uk/crypt/md5/md5src.html and then using the PHP md5 function on the server side and comparing the two results. That way the only thing that ever gets transmitted is an md5 hash =P Sheridan - Original Message - From: Jeff Bearer [EMAIL PROTECTED] To: Tom Malone [EMAIL PROTECTED] Cc: PHP Users [EMAIL PROTECTED] Sent: Thursday, July 19, 2001 12:17 PM Subject: Re: [PHP] encryption I'd use the password function in mysql to store encrypted passwords, I'd be interested to hear if anyone has a reason that doing this is not a good idea. On Thu, Jul 19, 2001 at 12:52:55PM -0400, Tom Malone wrote: Hello! I have a small problem. On my website there is some information I would like to protect. Right now I am using .htaccess to password-protect the directory, but I was thinking about using php and a form with usernames/passwords in a MySQL database. Thankfully, I read the following in the manual right before I was about to use the crypt() function to encrypt my password and compare it to the encrypted hash in the DB: It seems that a lot of people don't understand the point of using one-way encryption. More importantly, a lot of web designers forget that PHP encryption is done entirely on the web server, not the client. Point being, if your form has a password input option and the user clicks SUBMIT, the password is then sent _as plain text_ over the Internet to the web server where it is then encrypted for comparison against a password database
Re: [PHP] encryption
That is Complicated. if it's just for admins personal use, I'd say set up a secure sever and use your own certifiacate. On Fri, Jul 20, 2001 at 10:17:30AM -0400, Francis Fillion wrote: The best thing will be to sync clock, if it's in an other time zone just get your script to do +x or -x. Even they hours are not really important, except that if you use it as a key, they minutes are important. It's easy to sync time if it's for they admin, but for the user at large it's not possible. Or before sending your generated key you could get time from the server and generate they appropriate key using your key + time. For the client-side stuff, well it is not a problem for they admin of the site, since it will be they only one to use this kind of authentification, but if you want to use it for every user you need a key that both know, so even if you have they algorithm you need the key to have the good result. You could use the IP adress to make the key, both know it (well not really ...), some people will not be able to use it, people who work in a corporate environment and use internal IP adress in house and use an other IP adress when they get on they Imternet (masquering), so the IP adress on the client side and on the server side is not the same. Or at subscription time to make a cookie with the key and keep the key somewhere on the server side, extract the key only in the client side everytime after that to connect, so you only have a one time clear text key/password exchange on the net. Everytime after that a new key will be generated with the cookie key combined with the password and the samethings will be made on the server.You could even use the key to encrypt all data that are send to the server from the client, so that way you have a cheap secure connection, eh I'm starting to mimic SSH,SSL,...? Anyway whe could have fun making it! ;) P.S. Sorry for my crappy english, my native language is french so ... P.S.2. Sometime I talk about two key, I need a key (paraphrase?) to start my algorithm to have they final key. Sheridan Saint-Michel wrote: How do you get around the Server and client running on different times? I would think that would screw up the system as they would be generating them at different times? Other than that possible problem I like the idea. However, I would like to point out that anything done client-side can not be completely secure as anyone can get your algorithm from the JavaScript. Maybe You could devise some system with keys where the PHP page would write the Javascript Function with a different key based on time or something? That might work. Thoughts? Sheridan - Original Message - From: Francis Fillion [EMAIL PROTECTED] To: Tom Malone [EMAIL PROTECTED] Cc: PHP Users [EMAIL PROTECTED] Sent: Thursday, July 19, 2001 5:14 PM Subject: Re: [PHP] encryption One of my friends has a rsa key somethings, what it does is that at every few minutes it generate a random number so for login on his server he need this random key and his password to get in, the server generate the same key as his rsa key and has his password. SO the best things to do will be to make two program that use something to generate a random alphanumeric something on the server side and on your client side so when you connect to the server both have you has this key + your password, if it's OK it start a PHP session. And the key should be regenerated once you have login. SO even if somebody extract the clear text key+password from your connection he can't connect because this key+password is already passdue, the only possible attack then is to find the algorithm that you use+password, by changing your algorithm once in a while you can really limit this, they other attack could be a man in the middle attack, that could hurt. Good idea, I have to use this (let's put-it down on my project list,...), I could even put the generate stuff on my pda, I could login from anywhere... ;) Tom Malone wrote: I guess I should clarify - I'm just making a login for myself for the admin section of my website, so I only need to be able to protect my own password. I'm not sure if that information if helpful at all, but I haven't been able to figure out how to do it. Tom -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Thursday, July 19, 2001 3:21 PM To: Sheridan Saint-Michel Cc: php-general Subject: Re: [PHP] encryption Ahh, well then, another solution could be to use SSL, depends on your application weather you can get away with using an unsigned certificate (free) or weather you will need to pay a company like verisign to prove your identity. With an unsigned certificate the browser will warn the user that the certificate says it's
Re: [PHP] encryption
I'd use the password function in mysql to store encrypted passwords, I'd be interested to hear if anyone has a reason that doing this is not a good idea. On Thu, Jul 19, 2001 at 12:52:55PM -0400, Tom Malone wrote: Hello! I have a small problem. On my website there is some information I would like to protect. Right now I am using .htaccess to password-protect the directory, but I was thinking about using php and a form with usernames/passwords in a MySQL database. Thankfully, I read the following in the manual right before I was about to use the crypt() function to encrypt my password and compare it to the encrypted hash in the DB: It seems that a lot of people don't understand the point of using one-way encryption. More importantly, a lot of web designers forget that PHP encryption is done entirely on the web server, not the client. Point being, if your form has a password input option and the user clicks SUBMIT, the password is then sent _as plain text_ over the Internet to the web server where it is then encrypted for comparison against a password database. Do _not_ use these types of functions to add security to a form unless you're using an SSL or TLS (etc.) encrypted session. The only potential way around this issue is for you to write a JavaScript program that does the hashing on the client side before being sent over the Internet (which would make this function unnecessary). I am pretty new to PHP and absolutely clueless as far as encryption/algorithims are concerned. Could anyone possibly point me to a viable solution for this problem? Thanks in advance! Tom Malone -- PHP General 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] -- Jeff Bearer, RHCE Webmaster PittsburghLIVE.com -- PHP General 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] encryption
The problem he is addressing is that the password is sent plaintext to the server before it ever gets to MySQL. I would suggest using a JavaScript program like this http://pajhome.org.uk/crypt/md5/md5src.html and then using the PHP md5 function on the server side and comparing the two results. That way the only thing that ever gets transmitted is an md5 hash =P Sheridan - Original Message - From: Jeff Bearer [EMAIL PROTECTED] To: Tom Malone [EMAIL PROTECTED] Cc: PHP Users [EMAIL PROTECTED] Sent: Thursday, July 19, 2001 12:17 PM Subject: Re: [PHP] encryption I'd use the password function in mysql to store encrypted passwords, I'd be interested to hear if anyone has a reason that doing this is not a good idea. On Thu, Jul 19, 2001 at 12:52:55PM -0400, Tom Malone wrote: Hello! I have a small problem. On my website there is some information I would like to protect. Right now I am using .htaccess to password-protect the directory, but I was thinking about using php and a form with usernames/passwords in a MySQL database. Thankfully, I read the following in the manual right before I was about to use the crypt() function to encrypt my password and compare it to the encrypted hash in the DB: It seems that a lot of people don't understand the point of using one-way encryption. More importantly, a lot of web designers forget that PHP encryption is done entirely on the web server, not the client. Point being, if your form has a password input option and the user clicks SUBMIT, the password is then sent _as plain text_ over the Internet to the web server where it is then encrypted for comparison against a password database. Do _not_ use these types of functions to add security to a form unless you're using an SSL or TLS (etc.) encrypted session. The only potential way around this issue is for you to write a JavaScript program that does the hashing on the client side before being sent over the Internet (which would make this function unnecessary). I am pretty new to PHP and absolutely clueless as far as encryption/algorithims are concerned. Could anyone possibly point me to a viable solution for this problem? Thanks in advance! Tom Malone -- PHP General 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] -- Jeff Bearer, RHCE Webmaster PittsburghLIVE.com -- PHP General 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 General 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] encryption
Ahh, well then, another solution could be to use SSL, depends on your application weather you can get away with using an unsigned certificate (free) or weather you will need to pay a company like verisign to prove your identity. With an unsigned certificate the browser will warn the user that the certificate says it's you, but it's not proven by a CA so it might not be you. The JavaScript MD5 tenique is an interesting way of doing it, but i don't think it's any more secure. If a hacker sniffs the md5 hash how is that any diffrent than him sniffing a plain text password? You're comparing hashes, so as long as he has the hash he's in. On Thu, Jul 19, 2001 at 01:58:43PM -0500, Sheridan Saint-Michel wrote: The problem he is addressing is that the password is sent plaintext to the server before it ever gets to MySQL. I would suggest using a JavaScript program like this http://pajhome.org.uk/crypt/md5/md5src.html and then using the PHP md5 function on the server side and comparing the two results. That way the only thing that ever gets transmitted is an md5 hash =P Sheridan - Original Message - From: Jeff Bearer [EMAIL PROTECTED] To: Tom Malone [EMAIL PROTECTED] Cc: PHP Users [EMAIL PROTECTED] Sent: Thursday, July 19, 2001 12:17 PM Subject: Re: [PHP] encryption I'd use the password function in mysql to store encrypted passwords, I'd be interested to hear if anyone has a reason that doing this is not a good idea. On Thu, Jul 19, 2001 at 12:52:55PM -0400, Tom Malone wrote: Hello! I have a small problem. On my website there is some information I would like to protect. Right now I am using .htaccess to password-protect the directory, but I was thinking about using php and a form with usernames/passwords in a MySQL database. Thankfully, I read the following in the manual right before I was about to use the crypt() function to encrypt my password and compare it to the encrypted hash in the DB: It seems that a lot of people don't understand the point of using one-way encryption. More importantly, a lot of web designers forget that PHP encryption is done entirely on the web server, not the client. Point being, if your form has a password input option and the user clicks SUBMIT, the password is then sent _as plain text_ over the Internet to the web server where it is then encrypted for comparison against a password database. Do _not_ use these types of functions to add security to a form unless you're using an SSL or TLS (etc.) encrypted session. The only potential way around this issue is for you to write a JavaScript program that does the hashing on the client side before being sent over the Internet (which would make this function unnecessary). I am pretty new to PHP and absolutely clueless as far as encryption/algorithims are concerned. Could anyone possibly point me to a viable solution for this problem? Thanks in advance! Tom Malone -- Jeff Bearer, RHCE Webmaster PittsburghLIVE.com -- PHP General 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] encryption
I guess I should clarify - I'm just making a login for myself for the admin section of my website, so I only need to be able to protect my own password. I'm not sure if that information if helpful at all, but I haven't been able to figure out how to do it. Tom -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Thursday, July 19, 2001 3:21 PM To: Sheridan Saint-Michel Cc: php-general Subject: Re: [PHP] encryption Ahh, well then, another solution could be to use SSL, depends on your application weather you can get away with using an unsigned certificate (free) or weather you will need to pay a company like verisign to prove your identity. With an unsigned certificate the browser will warn the user that the certificate says it's you, but it's not proven by a CA so it might not be you. The JavaScript MD5 tenique is an interesting way of doing it, but i don't think it's any more secure. If a hacker sniffs the md5 hash how is that any diffrent than him sniffing a plain text password? You're comparing hashes, so as long as he has the hash he's in. On Thu, Jul 19, 2001 at 01:58:43PM -0500, Sheridan Saint-Michel wrote: The problem he is addressing is that the password is sent plaintext to the server before it ever gets to MySQL. I would suggest using a JavaScript program like this http://pajhome.org.uk/crypt/md5/md5src.html and then using the PHP md5 function on the server side and comparing the two results. That way the only thing that ever gets transmitted is an md5 hash =P Sheridan - Original Message - From: Jeff Bearer [EMAIL PROTECTED] To: Tom Malone [EMAIL PROTECTED] Cc: PHP Users [EMAIL PROTECTED] Sent: Thursday, July 19, 2001 12:17 PM Subject: Re: [PHP] encryption I'd use the password function in mysql to store encrypted passwords, I'd be interested to hear if anyone has a reason that doing this is not a good idea. On Thu, Jul 19, 2001 at 12:52:55PM -0400, Tom Malone wrote: Hello! I have a small problem. On my website there is some information I would like to protect. Right now I am using .htaccess to password-protect the directory, but I was thinking about using php and a form with usernames/passwords in a MySQL database. Thankfully, I read the following in the manual right before I was about to use the crypt() function to encrypt my password and compare it to the encrypted hash in the DB: It seems that a lot of people don't understand the point of using one-way encryption. More importantly, a lot of web designers forget that PHP encryption is done entirely on the web server, not the client. Point being, if your form has a password input option and the user clicks SUBMIT, the password is then sent _as plain text_ over the Internet to the web server where it is then encrypted for comparison against a password database. Do _not_ use these types of functions to add security to a form unless you're using an SSL or TLS (etc.) encrypted session. The only potential way around this issue is for you to write a JavaScript program that does the hashing on the client side before being sent over the Internet (which would make this function unnecessary). I am pretty new to PHP and absolutely clueless as far as encryption/algorithims are concerned. Could anyone possibly point me to a viable solution for this problem? Thanks in advance! Tom Malone -- Jeff Bearer, RHCE Webmaster PittsburghLIVE.com -- PHP General 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 General 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] encryption
One of my friends has a rsa key somethings, what it does is that at every few minutes it generate a random number so for login on his server he need this random key and his password to get in, the server generate the same key as his rsa key and has his password. SO the best things to do will be to make two program that use something to generate a random alphanumeric something on the server side and on your client side so when you connect to the server both have you has this key + your password, if it's OK it start a PHP session. And the key should be regenerated once you have login. SO even if somebody extract the clear text key+password from your connection he can't connect because this key+password is already passdue, the only possible attack then is to find the algorithm that you use+password, by changing your algorithm once in a while you can really limit this, they other attack could be a man in the middle attack, that could hurt. Good idea, I have to use this (let's put-it down on my project list,...), I could even put the generate stuff on my pda, I could login from anywhere... ;) Tom Malone wrote: I guess I should clarify - I'm just making a login for myself for the admin section of my website, so I only need to be able to protect my own password. I'm not sure if that information if helpful at all, but I haven't been able to figure out how to do it. Tom -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Thursday, July 19, 2001 3:21 PM To: Sheridan Saint-Michel Cc: php-general Subject: Re: [PHP] encryption Ahh, well then, another solution could be to use SSL, depends on your application weather you can get away with using an unsigned certificate (free) or weather you will need to pay a company like verisign to prove your identity. With an unsigned certificate the browser will warn the user that the certificate says it's you, but it's not proven by a CA so it might not be you. The JavaScript MD5 tenique is an interesting way of doing it, but i don't think it's any more secure. If a hacker sniffs the md5 hash how is that any diffrent than him sniffing a plain text password? You're comparing hashes, so as long as he has the hash he's in. On Thu, Jul 19, 2001 at 01:58:43PM -0500, Sheridan Saint-Michel wrote: The problem he is addressing is that the password is sent plaintext to the server before it ever gets to MySQL. I would suggest using a JavaScript program like this http://pajhome.org.uk/crypt/md5/md5src.html and then using the PHP md5 function on the server side and comparing the two results. That way the only thing that ever gets transmitted is an md5 hash =P Sheridan - Original Message - From: Jeff Bearer [EMAIL PROTECTED] To: Tom Malone [EMAIL PROTECTED] Cc: PHP Users [EMAIL PROTECTED] Sent: Thursday, July 19, 2001 12:17 PM Subject: Re: [PHP] encryption I'd use the password function in mysql to store encrypted passwords, I'd be interested to hear if anyone has a reason that doing this is not a good idea. On Thu, Jul 19, 2001 at 12:52:55PM -0400, Tom Malone wrote: Hello! I have a small problem. On my website there is some information I would like to protect. Right now I am using .htaccess to password-protect the directory, but I was thinking about using php and a form with usernames/passwords in a MySQL database. Thankfully, I read the following in the manual right before I was about to use the crypt() function to encrypt my password and compare it to the encrypted hash in the DB: It seems that a lot of people don't understand the point of using one-way encryption. More importantly, a lot of web designers forget that PHP encryption is done entirely on the web server, not the client. Point being, if your form has a password input option and the user clicks SUBMIT, the password is then sent _as plain text_ over the Internet to the web server where it is then encrypted for comparison against a password database. Do _not_ use these types of functions to add security to a form unless you're using an SSL or TLS (etc.) encrypted session. The only potential way around this issue is for you to write a JavaScript program that does the hashing on the client side before being sent over the Internet (which would make this function unnecessary). I am pretty new to PHP and absolutely clueless as far as encryption/algorithims are concerned. Could anyone possibly point me to a viable solution for this problem? Thanks in advance! Tom Malone -- Jeff Bearer, RHCE Webmaster PittsburghLIVE.com -- PHP General 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
RE: [PHP] encryption methods?
One approach to password security is to put the passwords in a file outside Document Root, then include that file in your scripts when you need a password. Kirk -Original Message- From: Adrian Teasdale [mailto:[EMAIL PROTECTED]] Sent: Friday, July 13, 2001 1:10 PM To: [EMAIL PROTECTED] Subject: [PHP] encryption methods? Hi all Encryption is not something that I have had dealings in with PHP. I have a potential client who wants to have customer account information (8000 records) stored on the internet (minus credit card information) and I was wondering what options I have for encryption. My concern is that by storing the password in php scripts, this means that all someone has to do is gain access to this to access the data. I'd be interested in other people's views and experiences with this. With thanks Ade -- PHP General 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 General 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] encryption methods?
check out the crypt() function http://www.php.net/manual/en/function.crypt.php if you don't care about decrypting the password this works fine. --Shaun On Friday 13 July 2001 15:26, Johnson, Kirk wrote: One approach to password security is to put the passwords in a file outside Document Root, then include that file in your scripts when you need a password. Kirk -Original Message- From: Adrian Teasdale [mailto:[EMAIL PROTECTED]] Sent: Friday, July 13, 2001 1:10 PM To: [EMAIL PROTECTED] Subject: [PHP] encryption methods? Hi all Encryption is not something that I have had dealings in with PHP. I have a potential client who wants to have customer account information (8000 records) stored on the internet (minus credit card information) and I was wondering what options I have for encryption. My concern is that by storing the password in php scripts, this means that all someone has to do is gain access to this to access the data. I'd be interested in other people's views and experiences with this. With thanks Ade -- PHP General 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 General 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] encryption methods?
Butler, Shaun pressed the little lettered thingies in this order... check out the crypt() function http://www.php.net/manual/en/function.crypt.php if you don't care about decrypting the password this works fine. --Shaun Umm... You've misunderstood something. The reason why you would WANT to use mcrypt is because you CAN decrypt data that it has encrypted. For encryption: http://www.php.net/manual/en/function.mcrypt-encrypt.php For decryption: http://www.php.net/manual/en/function.mcrypt-decrypt.php I use mcrypt when I need to store data that must be encrypted in the DB, but must also be decrypted on the way out (including passwords and credit card numbers). The only reason you would need to decrypt passwords is if you want to view them or if you want to make it possible to have passwords mailed to people who forget theirs. If you don't need decrypt capabilities, most (all?) SQL database servers have support for one-way encryption. It's not efficient to store user data in PHP scripts (or any other script for that matter) as was stated in the initial message. If you have access to a database server, use it. Christopher Ostmo a.k.a. [EMAIL PROTECTED] AppIdeas.com Innovative Application Ideas Meeting cutting edge dynamic web site needs since the dawn of Internet time (1995) For a good time, http://www.AppIdeas.com/ -- PHP General 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] Encryption (Browser Side)
Don't know much about LDAP so I can't answer those questions, but the only way (short of creating/requiring a plug-in just to encrypt the data, which isn't a good idea) to have the user send an encrypted password is to use SSL on the login/creation page. That means you can't ever send their password through the url of a non-SSL page for security, but you shouldn't do that anyway. That's the only browser side encryption that all browsers support. -- Plutarck Should be working on something... ...but forgot what it was. Jason Mowat [EMAIL PROTECTED] wrote in message 9c1rja$5kp$[EMAIL PROTECTED]">news:9c1rja$5kp$[EMAIL PROTECTED]... Greets, I have a question about PHP and browser-side encryption. I currently authenticate my users to an LDAP system using the PHP LDAP APIs. The user enters their login name and password on a browser form, with the password box being set to all '*'s for password. However, this information is sent 'plaintext' to the LDAP server, so an interloper could potentially sniff the password off of the network. The second issue is that I am also presented with a way in which to grab the user's password, simply by saving the contents of the password field and dumping it to a text file or database from the PHP code. My question is: what is the best way for me to do an LDAP bind without having access to the password in plaintext? Can I encrypt the password as the user types it in on the browser window, so that no form type variables can be trapped by PHP? SSL will address the encryption of the passwords after they are sent to the LDAP server, but it is probably a little bit of overkill to encrypt the entire stream. It also permits me to steal passwords from the PHP side, which is a security consideration. What is the best, easiest solution for me to follow? Cheers, Jason -- PHP General 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 General 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] Encryption Problem
quite possibly you did not compile PHP with mcrypt library support. for linux distrib's, mcrypt is not default, you have to specify ./configure --with-mcrypt to get mcrypt functionality (i dont know whether it's included by default with the win binary, but i doubt it) do the phpinfo() thing and see if mcrypt is there. -Original Message- From: darion mapp [mailto:[EMAIL PROTECTED]] Sent: Thursday, March 22, 2001 5:19 PM To: [EMAIL PROTECTED] Subject: [PHP] Encryption Problem ok, so i have want to encrypt my user password in the mySQL Database and well that is not working but in addition to that when the user logges into the system i have to encrypt their password and compare the two encrypted passwords to see if they match. this is where my problem starts. I get the same error for both the registration process where the password is encrypted to be placed into the database and when the use logs in and the password is encrypted to be compared. The web browser errors to "Page cannot bbe displayed (IE)" and only when the line below is commented out does it work fine. HELP Project was due last week so i am pressed for time $txtPass = mcrypt_ecb(MCRYPT_BLOWFISH, $key, $txtPass, MCRYPT_ENCRYPT); Get 250 color business cards for FREE! at Lycos Mail http://mail.lycos.com/freemail/vistaprint_index.html -- PHP General 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 General 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] Encryption
I am trying to do a simple encryption on a credit card number to store in a mysql text field. I also have to de-crypt the number after exporting to an access db. I tried to use xor encryption, but it seems to only work half the time, the other half, I can't seem to de-crypt the # properly, some of the numbers end up screwed. Is this because of the way mysql is storing the field? Mabye it can't recognize some of the characters that are generated from the xor encryption? Ex: 123456789123 may end up 1 YdR and then de-crypts to 1234(*$8912# Is it the that are the problem? Or is the the access database that isn't properly storing the ? Yes, those are the problems. You are XOR-ing and getting invalid characters. You could URLEncode/URLDecode it, or Base64_Encode/Base64_Decode or some other way of guaranteeing that your databases don't have to deal with funky characters. Is there a better way to do this? This is a *really* bad idea, all around. Either the place you are storing the credit card numbers is "secure enough" that encrypting them is pointless, or it's not secure enough at all, and your encryption won't stop anybody who wants those numbers. You shouldn't be storing nor transporting credit card numbers insecurely. XOR-encryption is not secure, by definition. -- Visit the Zend Store at http://www.zend.com/store/ Wanna help me out? Like Music? Buy a CD: http://l-i-e.com/artists.htm Volunteer a little time: http://chatmusic.com/volunteer.htm -- PHP General 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]
