tags:

views:

533

answers:

10

How can I have a password inside PHP code and guarantee that no one viewing the page in the browser can retrieve it?

Is, for example, <?php $password = 'password' ?> enough? Is there a better, more secure way of doing this?

Thanks.

+3  A: 

Store the password encrypted. For example, take the output of:

sha1("secretpassword");

...and put it in your code. Even better, put it in your database or in a file outside of the web server's directory tree.

Jeff Ober
Putting database passwords into the database calls for some ... interesting problems :-)
Joey
+1 this is the only sane solution! shame on all the others (i.e. php will be parsed, so one one can see your passwords :-S)
knittl
SHA is *not* an encryption. It’s a hash algorithm.
Gumbo
How does this help? One presumes the password allows access to some secure resource. If the hash is enough to access this resource, how is storing the hash any more secure than storing the raw password - both will allow access?
Adam Wright
be sure to use salt: sha1 can be broken using a rainbow table relatively easily.
Martijn
Most of the time you want to store passwords in your code, they're for connecting to resources such as databases, and I've never seen a database accept a hashed password for a connection before...
nickf
+5  A: 

Your PHP code will (baring configuration errors) be processed on the server. Nothing inside <?php ?> blocks will ever be visible on the browser. You should ensure that your deployment server will not show syntax errors to the client - i.e. the error reporting is set to something not including E_PARSE, lest a hasty edit of live code (admit it, we all do them :) leak some information.

Edit: The point about storing them in a file outside the document root to avoid exposure if your PHP configuration breaks is certainly valid. When I used PHP, I kept a config.inc file outside of htdocs that was require'd at runtime, and exported configuration specific variables (i.e. passwords).

Adam Wright
that's not a good solution. and what if you’re working in a team, in which everybody has access to the sourcecode. no, no, no! hashing is the way to go
knittl
How does hashing help? If the hash is enough to connect to the "secure" resource, how is storing the hash any more secure than storing the password?
Adam Wright
usually there are two scenarios. see [my answer](http://stackoverflow.com/questions/1432545/how-to-safely-store-a-password-inside-php-code/1432589#1432589), it talks about both
knittl
what sort of project is this where some team members don't have admin access to their own system?
nickf
...and if such a team exists - one where you can't trust one of them with a password - you should really reconsider working with them in the first place.
nickf
but you wouldn’t give your workplace password to everybody in your team, am i right? better safe than sorry
knittl
+1  A: 

Basic, probably not 100% watertight but enough for general purposes:

has the password (use salt for added security) using your favorite algorithm, and store the hash (and the salt). Compare salted & hashed input with stored data to check a password.

Martijn
+2  A: 

There are noumerous ways of doing this. However, people will not be able to view the password you stored (as plain text) in a PHP file, since PHP is a server side language which means that, as long as you don't print it out to the browser, it will remain invisible.

So it's 'safe'.

MiRAGe
A: 

PHP code blocks cannot be retrieved by clients unless they output something. Observe:

<?php
   if($password=="abcd")
       echo "OK";
   else
       echo "Wrong.";
?>

User can get either OK or Wrong nothing else.

Cem Kalyoncu
Unless you accidentally uninstall PHP and Apache starts serving it as plain text, that is. Seen that happen a few times!
ceejayoz
Also there's the ubiquitous way of getting to file contents by putting things like `../../../../../etc/passwd` somewhere in the URL :-). But granted, that works whenever you don't pay attention to what the user enters and have something sensitive stored in a file.
Joey
A: 

The best way is to store password above your root directory. If you decide to have password in php file then no body would able to view because php files are excuted in the server. But if the server does not support php then those files will be delivered as text files and any one can see the password.

Mohamed
And where do you store the database password?
innaM
folder/directory above root directory, so that no one can directly access it in the browser.
Mohamed
So what is your answer? Store the password in the database or store it in a file above the document root?
innaM
changed, but I thought that he was asking about user login password, not the database password.
Mohamed
+7  A: 

that depends on the type of passwords you want to store.

  • if you want to store passwords to compare against, e.g. having an $users array, then hashing is the way to go. sha1, md5 or any other flavor (here’s an overview)

    adding a salt accounts for additional security, because the same password will not result in the same hash

  • if you want to store passwords to connect to other resources like a database: you’re safest if you store your passwords outside your document root, i.e. not reachable by browsers. if that's not possible, you can use an .htaccess file to deny all requests from outside

knittl
i don't see how storing the passwords outside the document root really changes anything. As long as it's in `<?php` tags, then it won't be sent to the client.
nickf
"only" if the files will be processed by PHP...A nuked PHP Installation could cause them to be send to the client in clear text
Heiko Hatzfeld
+1  A: 

If you can retrieve the password within PHP, then it is retrievable...

The only thing that you can do is to move you password to a "protected" location.

Most hosters will offere a seperate location where you can place your DB files etc, and this location will not be accessable via the browser. You should store passwords there.

But they are still on your server, and when someone gets access to your box, then he has your password. (He gets to your PHP that has the way to decode it, and he has access to the protected file -> he can read it)

So there is no such thing as a "safe password"

[Edit - to much text to comment on the comment from Kieveli ;)] I dont believe in it...

The only option YOU have is to not STORE PASSWORDS for your users etc... I allways get mad if i subscribe to a service, and they offer to send me my password via email in case i forget it... Thats not a good practice.. They store it in a "retrievable way", and thats no something you should do.

Thats where all the hashing & salting etc comes in. You want to veryfiy that someone can access a ressource. So you hash + salt the password, and store that in the DB for the USER who want to access the service, and when the user wants to authenticate you apply the same algorythem to create the hash and compare those... (Or even better: You use OpenID, and let the OpenID provider care about all this)

If you "as a PROGRAMM" have to access something (Database etc...), then thats usually not an option, since you need that password to authorize yourself as the application.

Heiko Hatzfeld
Exactly... but I wonder if adding random safeguards can help reduce liability if passwords get stolen. I worked with a guy who scrambled passwords to a database inside fields in the database. I'm still confused. It made it difficult to work with when you wanted the application to point to a different database with a different password.
Kieveli
+1  A: 

Let's say your password is "iamanuisance". Here's how to store the password in your code. Just slip this in your header somewhere.

//calculate the answer to the universe
${p()}=implode(null,array(chr(0150+floor(rand(define(chr(ord('i')+16),'m'),
2*define(chr(0x58),1)-0.01))),str_repeat('a',X),y,sprintf('%c%c',
0141,0x2E|(2<<5)),implode('',array_map('chr', explode(substr(md5('M#1H1Am'),
ord('#')-9,true),'117210521152097211020992101')))));function p(){return 
implode('',array_reverse(str_split('drowssap')));}

Just in case it's not completely obvious, you can then easily access the password later on as $password. Cheers! :P

brianreavis
yuck! security through obscurity is not working. period.
knittl
haha, ditto. it was only meant as a joke ;)
brianreavis
A: 

I generally do not trust raw PHP code for passwords for services. Write a simple PHP extension to release the password. This ensures that the working set is password free, and it makes it an extra step for a compromised machine to grant access to the hacker to the service.

MathGladiator