0

I want a very simple login functionality integrated into a form on my server. It would be for use with only one page. You login in order to upload files to the server. I use a Linux at the moment. Does anyone have an idea of where I could get an idea where to get started. I have HTTPS/SSL Certificate on the server so it will help. But I don't really want to get complicated, only enough to stay secure. Ideas? Hope I'm in the right place. I'd like to use PHP to do this. The goal is to create a login without using SQL maybe, as it is only for one or two users.

Solo
  • 726
  • 1
  • 9
  • 18
  • $_SESSION variables are secure enough for any site with less than about a million users. Set them like, `$_SESSION['user']['id']=user_id;` The only issue comes in is session hijacking, which you can Google if you're interested. – Connor Peet May 21 '12 at 15:59
  • Do you trust your users? Ignoring the authentication issue, secure untrusted file upload is *very* difficult to get right. – bobince May 21 '12 at 22:35

3 Answers3

0

You could just use htaccess to password-protect a directory (cpanel/plesk make this easy to do), or give your users an FTP account to upload files.

Either one would be quick and easy to setup, with FTP being more secure (assuming a reasonable password).

Chris Fletcher
  • 2,367
  • 1
  • 16
  • 19
  • It's for a client, I found the .htaccess to not be very user-friendly for what it is. But thanks for the tip regardless. :) – Solo May 21 '12 at 16:06
0

Something like, 

$hash = "precomputed hash of your password";
if (crypt($_POST['password'], '$6$rounds=5000$usesomesillystringforsalt$') == $hash)  {
   ...
}

No database is needed.

Lie Ryan
  • 62,238
  • 13
  • 100
  • 144
  • I was about to post something very similar, but then I thought: what's the point of salting/hashing the password in this case? If someone breaks into the server and gains access to the PHP script, they'll know the salt, and can change the password anyway... – bfavaretto May 21 '12 at 16:09
  • @Lie Ryan,Going to try this now, thank you I'll post soon if it works. – Solo May 21 '12 at 16:10
  • @bfavaretto well if someone breaks into the server they'll have access to ALL data, so what would be the point of changing the password...? just my little thought :) – giorgio May 21 '12 at 16:11
  • @giorgio, agreed, so what's the point of hardcoding a salted/hashed password instead of the plain text version? If it was stored in a db, I would understand it, but in PHP? – bfavaretto May 21 '12 at 16:14
  • If someone was able to read the PHP script, they could find out the credentials to access a database that way too? So I don't get it. Why argue? – Solo May 21 '12 at 16:21
  • @bfavaretto well because if you save the password plain text you can just login, if you save it in a hashed version, you can only check if the given password is the same (the idea behind hashed passwords is that it's encoded one-way, meaning you cannot 'decode' the password). So if you have the salt and the hash you can only use them to brute-force the password on your own pc (ofcourse the server has some kind of protection against it ;)), so it takes a lot of effort – giorgio May 21 '12 at 16:21
  • 1
    @giorgio, I'm still not sure, and decided to ask a question about it: http://stackoverflow.com/q/10689257/825789 – bfavaretto May 21 '12 at 16:49
  • A salt value must, by its very definition, be random. If you choose a static value, your 'salt' becomes a 'key'. – Jacco May 23 '12 at 10:09
  • @Jacco: it need not be, as long as each password (if the system can authenticate multiple users) has different salts, then the system will be just as secure. The point of a salt is to topple rainbow tables, and having a static salt doesn't make the system any less secure. The point of a salt is so that you can reuse the same password but the hash will be different each time because the salt is different. Yes, to be any secure, you'll need to change your salt if you need to change your password, but in this database-less system changing password means modifying the script anyway. – Lie Ryan May 23 '12 at 13:01
  • @Lie Ryan, Technically, the salt should be unique and non-predicatbale. This is meant worldwide. Since there is no central organization which distributes unique salts on demand, we have to rely on the next best thing: random selection with an unpredictable random generator, preferably within a salt space large enough to make collisions improbable. It is tempting to try to derive a salt from some data which is "presumably unique", but such schemes often fail due to some overlooked details. A static salt would let the attacker share the cost of an attack amongst more than one target hash. – Jacco May 24 '12 at 07:59
  • @Lie Ryan, The requirement for hashing the password does not change because of the storage medium chosen. In a database-less system, the accepted method for storing information is files. This choice does not, in any way, change the need for a (random) salt. There is no such thing as a 'static salt'; in cryptography, this static value would be called 'a key'. Since the comments only allow limited length reactions, I invite you to read [my long answer on salting](http://stackoverflow.com/questions/1645161/salt-generation-and-open-source-software/1645190#1645190). – Jacco May 24 '12 at 08:05
  • @Jacco: you said it yourself, the requirement does not change. However, because of the limitation that the server cannot modify the script to modify someone's hash or salt, if the legitimate administrator want to change his password, he had to pick a different salt (e.g. possibly through a RNG), recalculate the new hash, and modify the script manually with a text editor; that is what I meant by "static salt". Apart from that misunderstanding, I believe we're in agreement with each other, either that or I'm not getting what you're trying to say. – Lie Ryan May 24 '12 at 14:12
  • we are largely on the same page. However, the password hashes should not be stored in the script, but in a separate password file. The script should create/modify this file as needed. – Jacco May 26 '12 at 12:47
  • @Jacco: doing that would negate the main selling point of this auth scheme, which is to be "simple", yet secure. If I want the authentication script to allow changing password, I'll be using CSV or sqlite instead. If this script is read-only, it is more secure than using database or a separate writable file; on the other hand, if you had used separate read-only file, then it's not as simple as it possibly could be. – Lie Ryan May 27 '12 at 09:11
-1

its easy, you just nees to filter input so that your script save from sql injection, if you want to build this functionality on same page then u must use propper conditions to check incoming post data,

php's FILTER_SANITIZE_(check string,password,number,or other things) is very handy in this way

jugnu
  • 141
  • 6