[PHP] Re: why are passwords stored encrypted in databases even when thedatathey protect is stored in the same database?
On Fri, 2008-06-13 at 14:20 +0200, M. Sokolewicz wrote: > Considering you're already jailing access by linking a specific url to a > specific password you're making the impact of a hacked password pretty > small. Which is a good thing :) > I would recommend, if you go this way, to add an expiry date to the > url/password combo. So for example you can only use that url/password > combo for 3 days before it expires, after that, you need a new combo. > Doing it this way (with server-generated passwords) you make sure that > _if_ it were ever to fall into hands-it-should-not-be-in, it won't be > there for long. > > - Tul > > P.S. in other words, sounds fine to me :) Thank you again! ...so finally I can get to work :) Best wishes, Dietrich On Fri, 2008-06-13 at 14:20 +0200, M. Sokolewicz wrote: > Dietrich Bollmann wrote: > > Hi tul, > > > > So this was a very long and informative answer :) > > Thank you very much! > > > > On Fri, 2008-06-13 at 12:02 +0200, M. Sokolewicz wrote: > >> [...] However, people usually write code which may (and will most > >> of the time) containt exploitable sections which might give a malicious > >> user the ability to get a dump of the database. A password dump is > >> always interesting, since it gives a LOT of information. People usually > >> don't use 1 password per login, but rather have a "standard password" > >> for most things. > > > > So if the user is allowed to change his password, it should be encrypted > > always as there are chances that the same password is used at some other > > place? That makes a lot of sense to me :) > > > > If all passwords are generated by the system on the other hand and the > > user is not allowed to change his password, if further all the protected > > data is in the same database as the password, there would be no need for > > encrypting the passwords following your argumentation? > > > > But if some information is stored outside the database - in my case > > (simple file server) for example, the database only contains the file > > meta-data while the files themselves are stored in some data directory > > on the server - some malicious user who would have broken into the > > database could get hold of the files if the passwords are stored > > unencrypted; if some encryption scheme would have been used on the > > other hand the data found in the database wouldn't be of any use at all? > > > > And if the password should be recoverable some encryption with a key > > stored somewhere else would force the hacker to break into two systems, > > the database itself and the system which is used to store the key. > > > > That makes sense also. I didn't think about the fact that database and > > a directory on the server are two different things which would have to > > be hacked separately. So I am happy about writing my mail and getting > > such a nice answer before implementing some stupid password logic > > myself :) > > > >> Now, if it were unprotected, the person getting the information can > >> instantly log in as that user, or if he wants might even take over that > >> person's identity in other places (rare, but it happens). If it were > >> protected by encryption of some kind then it would first need to be > >> decrypted to be usable (unless there is a designflaw which makes this > >> unnecessery as has been the case in a few messageboards a few years ago). > >> Now, you can either encrypt or hash your passwords. Hashes are one-way, > >> encryption two-way. If the malicious user gets hold of a hash: he'll > >> still not have anything useful in his hands. He might make a reverse > >> lookup table and figure out the password from that (though there's an > >> infinite number of possible inputs for each single [hash] output), but > >> add a salt and don't put that in the database and the user has a low > >> chance of ever finding out what it was. But, just as the malicious user > >> can't figure out what the password was, neither can you: so goodby > >> lost-password feature. Instead you'd have to regenerate a new password > >> and send that over, or do some other fancy magic which doesn't involve > >> sending the current password as-is, since you don't know it either. > >> If you were to use encryption there, you could always decrypt it. If you > >> have the key. Storing the key separately from the encrypted password > >> would make this quite saf
[PHP] Re: why are passwords stored encrypted in databases even when the datathey protect is stored in the same database?
Hi tul, So this was a very long and informative answer :) Thank you very much! On Fri, 2008-06-13 at 12:02 +0200, M. Sokolewicz wrote: > [...] However, people usually write code which may (and will most > of the time) containt exploitable sections which might give a malicious > user the ability to get a dump of the database. A password dump is > always interesting, since it gives a LOT of information. People usually > don't use 1 password per login, but rather have a "standard password" > for most things. So if the user is allowed to change his password, it should be encrypted always as there are chances that the same password is used at some other place? That makes a lot of sense to me :) If all passwords are generated by the system on the other hand and the user is not allowed to change his password, if further all the protected data is in the same database as the password, there would be no need for encrypting the passwords following your argumentation? But if some information is stored outside the database - in my case (simple file server) for example, the database only contains the file meta-data while the files themselves are stored in some data directory on the server - some malicious user who would have broken into the database could get hold of the files if the passwords are stored unencrypted; if some encryption scheme would have been used on the other hand the data found in the database wouldn't be of any use at all? And if the password should be recoverable some encryption with a key stored somewhere else would force the hacker to break into two systems, the database itself and the system which is used to store the key. That makes sense also. I didn't think about the fact that database and a directory on the server are two different things which would have to be hacked separately. So I am happy about writing my mail and getting such a nice answer before implementing some stupid password logic myself :) > Now, if it were unprotected, the person getting the information can > instantly log in as that user, or if he wants might even take over that > person's identity in other places (rare, but it happens). If it were > protected by encryption of some kind then it would first need to be > decrypted to be usable (unless there is a designflaw which makes this > unnecessery as has been the case in a few messageboards a few years ago). > Now, you can either encrypt or hash your passwords. Hashes are one-way, > encryption two-way. If the malicious user gets hold of a hash: he'll > still not have anything useful in his hands. He might make a reverse > lookup table and figure out the password from that (though there's an > infinite number of possible inputs for each single [hash] output), but > add a salt and don't put that in the database and the user has a low > chance of ever finding out what it was. But, just as the malicious user > can't figure out what the password was, neither can you: so goodby > lost-password feature. Instead you'd have to regenerate a new password > and send that over, or do some other fancy magic which doesn't involve > sending the current password as-is, since you don't know it either. > If you were to use encryption there, you could always decrypt it. If you > have the key. Storing the key separately from the encrypted password > would make this quite safe. enctpyed_string = (data + key), if you know > neither the data nor the key, things get very tough. Because you know > the key, you can figure out the password and make a forgot-password > feature easily which sends out the actual password. > But, because your key is publicly available (if your page has to use it, > then it's automatically publicly available, maybe not easily, but a > malicious user which managed to get hold of a full password table, could > just aswell get hold of the key for the encryption)! > Putting in neither, so just keeping the passwords in their plain form is > safe. As long as noone _ever_ sees them. Guarantee that and you won't > have to bother with hashing/encrypting. If you can't guarantee it, build > in some extra safety in the form of hashing and/or encrypting. > > hope that explains it all a bit, > - tul Yes. A bit. I am actually impressed. But I better read some more redundant book about intelligent malicious users as I still feel like not understanding everything of what you said completely. ...any nice book recommendation for naive people like me :? So how about the following solution to my simple file-server problem: I generate a new url for every user who is allowed to download a file and a private password for every new url. Using this approach, the same file will be downloaded by different users via different urls and passwords. The password for an url is stored in the database encrypted and send over to the user unencrypted per email. Of course this makes some more logic and tables necessary - and a new row for every user also - bu
[PHP] why are passwords stored encrypted in databases even when the data they protect is stored in the same database?
Hi, As far as I remember, in all books I read about PHP and SQL, the password was stored in an encrypted form, even when all the data which should be protected by the password was stored in the same database. Can anybody tell me what is the motivation behind this approach? If somebody hacks the database, he has the data anyway; if he doesn't, he can't retrieve the password, encrypted or not. I am asking because I would like to implement a simple file server. A user would upload his files and get them listed on his user page. If he wants to allow some other person to download the file, he pushes a button beside the file entry in the listing and a page opens where he can enter the email of the other person. An email is send with the link where the file can be found and a password included... The person who asked me to write this file server wants everybody who to receive the same link together with the same password for the same file. In order to implement this approach, the password has to be stored somewhere... I thought about storing the password as it is in the database - but somehow wonder why this never was done in any of the books I read... By the way: in most cases, when pushing the "I forgot my password" button, an email with a user name and a link to activate the password is generated. Anybody who gets into the possession of the email could access the data... Should I rather send two emails, one with the link, one with the new password? Thanks for your help :) Dietrich -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] SetEnv directives in VirtualHost configuration not accessible in PHP
Hi Iv and Dmitri,
Thanks for your help!
The solution to my problem came under the shower - as usual :)
I have to admit that I would prefer to not tell you the truth ... but:
I did all my configuration in the httpd.conf of another
project ... ... :) :( :) :)
...sometimes it is wiser to sleep about a problem before stealing other
peoples time... (and sometimes, unfortunately, the opposite is true).
Thank you again, Dietrich
On Fri, 2008-05-16 at 14:24 +0200, Iv Ray wrote:
I had similar problem some time ago, and there was some solution, which
> I can't remember now.
>
> Do you still have the problem?
>
> I'll can have a look, if still needed.
>
> Iv
On Fri, 2008-05-16 at 10:10 -0400, Dmitri wrote:
If you are on apache2 server, try |$myvar =
> apache_getenv("|APP_CONFIG_SECTION|");
> echo $myvar
> and see if it has value that you expect
> Dietrich Bollmann wrote:
>
> >Hi,
> >
> >I have the following directive in my virtual host configuration:
> >
> > SetEnv APP_CONFIG_SECTION "development"
> >
> >and would like to access the value from PHP with
> >getenv('APP_CONFIG_SECTION') or $_SERVER['APP_CONFIG_SECTION'] or
> >whatever. But none of them work.
> >
> >Is there any PHP / Zend / Apache2 / ... configuration option etc. I
have
> >to activate / deactivate in order to use SetEnv?
> >
> >I am using the Debian packate apache / php installation and the
current
> >version of the Zend Framework.
> >
> >I tried to use `safe_mode_allowed_env_vars = PHP_, APP_CONFIG_' in
> >php.ini - but this didn't change anything either.
> >
> >mod_env seems to be loaded also: /etc/apache2/mods-enabled/env.load
> >-> ../mods-available/env.load
> >
> >Thanks, Dietrich
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] SetEnv directives in VirtualHost configuration not accessible in PHP
Hi,
I have the following directive in my virtual host configuration:
SetEnv APP_CONFIG_SECTION "development"
and would like to access the value from PHP with
getenv('APP_CONFIG_SECTION') or $_SERVER['APP_CONFIG_SECTION'] or
whatever. But none of them work.
Is there any PHP / Zend / Apache2 / ... configuration option etc. I have
to activate / deactivate in order to use SetEnv?
I am using the Debian packate apache / php installation and the current
version of the Zend Framework.
I tried to use `safe_mode_allowed_env_vars = PHP_, APP_CONFIG_' in
php.ini - but this didn't change anything either.
mod_env seems to be loaded also: /etc/apache2/mods-enabled/env.load
-> ../mods-available/env.load
Thanks, Dietrich
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Problems with mime encoding of Japanese Characters in Subject and 'From:', 'Reply-to:', ... fields.
Hi - in order to see the Japanese Characters in the previous mail you might have to switch the "Character Encoding" of your Email reader to Unicode (UTF-8). In my case (I am using the "Evolution" mail program on Linux): View > Character Encoding > Unicode (UTF-8) Dietrich On Thu, 2008-03-20 at 16:06 +0900, Dietrich Bollmann wrote: > I try to send messages written in Japanese (Kana/Kanji) with php. > > Everything works fine - only when the subject (or the name of the > sender) becomes longer, there seems to be something wrong with the > encoding: Neither my nor the mail reader of other (Japanese) friends > decodes the mime string. At the place of the Japanese Characters, > the mime string itself is displayed in the subject (to, reply to) > field. > > As this doesn't happen for other Japanese emails with even longer > subjects, I suppose I did something wrong ... but what? -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Problems with mime encoding of Japanese Characters in Subject and 'From:', 'Reply-to:', ... fields.
Hi,
--- note ---
I sent a similar message already to php-i18n - but this list seems
not to be used very much (20 messages this year) so I am posting it
here again...
I try to send messages written in Japanese (Kana/Kanji) with php.
Everything works fine - only when the subject (or the name of the
sender) becomes longer, there seems to be something wrong with the
encoding: Neither my nor the mail reader of other (Japanese) friends
decodes the mime string. At the place of the Japanese Characters,
the mime string itself is displayed in the subject (to, reply to)
field.
As this doesn't happen for other Japanese emails with even longer
subjects, I suppose I did something wrong ... but what?
Here how I convert the subject (the name is converted using the same
method and the sources are saved in UTF-8 using emacs):
$subjectJIS = mb_convert_encoding($subject, "ISO-2022-JP", "AUTO");
$subjectMIME = mb_encode_mimeheader($subjectJIS, "ISO-2022-JP", "B");
...snip...
mail($to, $subjectMIME, $bodyJIS, $headers);
Here part of the message as it is displayed by my mail program:
From:
=?ISO-2022-JP?B?GyRCJCskSjRBO3okKyRKNEE7eiQrJEo0QTt6JCskSjRBO3okKyRKNEE7?==?ISO-2022-JP?B?eiQrJEo0QTt6JCskSjRBO3okKyRKNEE7eiQrJEo0QTt6JCskSjRBO3ob?=(B
<[EMAIL PROTECTED]>
...snip...
Subject:
=?ISO-2022-JP?B?GyRCJCskSjRBO3okKyRKNEE7eiQrJEo0QTt6JCskSjRBO3okKyRKNEE7?=
=?ISO-2022-JP?B?eiQrJEo0QTt6JCskSjRBO3okKyRKNEE7eiQrJEo0QTt6JCskSjRBO3ob?= (B
...snip...
かな漢字かな漢字かな漢字かな漢字かな漢字かな漢字かな漢字かな漢字かな漢
字かな漢字
And here part of the mail text itself:
...snip...
Subject:
=?ISO-2022-JP?B?GyRCJCskSjRBO3okKyRKNEE7eiQrJEo0QTt6JCskSjRBO3okKyRKNEE7?=
=?ISO-2022-JP?B?eiQrJEo0QTt6JCskSjRBO3okKyRKNEE7eiQrJEo0QTt6JCskSjRBO3ob?=
=?ISO-2022-JP?B?KEI=?=
MIME-Version: 1.0
From:
=?ISO-2022-JP?B?GyRCJCskSjRBO3okKyRKNEE7eiQrJEo0QTt6JCskSjRBO3okKyRKNEE7?=
=?ISO-2022-JP?B?eiQrJEo0QTt6JCskSjRBO3okKyRKNEE7eiQrJEo0QTt6JCskSjRBO3ob?=
=?ISO-2022-JP?B?KEI=?= <[EMAIL PROTECTED]>
...snip...
Content-Type: text/plain; charset=ISO-2022-JP
...snip...
かな漢字かな漢字かな漢字かな漢字かな漢字かな漢字かな漢字かな漢字かな漢
字かな漢字
Here a part of another (spam) mail which is correctly displayed by my
mail program:
MIME-Version: 1.0
Subject:
=?ISO-2022-JP?B?GyRCIXolXSUkJXMlSBsoQjEwGyRCR1whdUF3TkEbKEI=?=
=?ISO-2022-JP?B?GyRCTDVOQSF6GyhCMSwwMDAbJEIxXyU4JWUbKEI=?=
=?ISO-2022-JP?B?GyRCJSglaiE8Qmc9ODlnISohWjNaRTchWxsoQg==?=
=?ISO-2022-JP?B?GyRCIUobKEIyMDA4LzAzLzE5?= =?ISO-2022-JP?B?KQ==?=
From: =?ISO-2022-JP?B?GyRCM1pFNztUPmwlOCVlJSglaiE8ISYlIhsoQg==?=
=?ISO-2022-JP?B?GyRCJS8lOyU1JWohPCVLJWUhPCU5GyhC?=
<[EMAIL PROTECTED]>
Displayed as:
From: 楽天市場ジュエリー・アクセサリーニュース
<[EMAIL PROTECTED]>
...snip...
Subject: ★ポイント10倍＆送料無料★1,000円ジュエリー大集合！【楽天】
（2008/03/19)
If anybody can explain me the problem I would be most grateful :)
Thanks, Dietrich
---
PS: I appended a little example program which produces the problem.
The same program works correctly when using the following values:
$subject = "かな漢字";
$senderName = "かな漢字";
Thanks for your help :)
http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd";>
http://www.w3.org/1999/xhtml"; xml:lang="en" lang="en">
Contact Me
かな漢字
", $senderNameMIME,
$senderEmailAddress);
// formatting the mime header
$headers = "MIME-Version: 1.0\n" ;
$headers .= sprintf("From: %s\n", $senderMIME);
$headers .= sprintf("Reply-To: %s\n", $senderMIME);
$headers .= "Content-Type: text/plain; charset=ISO-2022-JP\n";
// send encoded mail
$result = mail($recipientEmailAddress, $subjectMIME, $bodyJIS,
$headers);
// return result
return $result;
}
$to = "[EMAIL PROTECTED]";
$subject= "かな漢字かな漢字かな漢字かな漢字かな漢字かな漢字
かな漢字かな漢字かな漢字かな漢字";
$body = "かな漢字かな漢字かな漢字かな漢字かな漢字かな漢字
かな漢字かな漢字かな漢字かな漢字";
$senderName = "かな漢字かな漢字かな漢字かな漢字かな漢字かな漢字
かな漢字かな漢字かな漢字かな漢字";
$senderEmailAddress = "[EMAIL PROTECTED]";
// send the email
sendEmail($to, $subject, $body, $senderName, $senderEmailAddress);
?>
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
