-1

So i know you are going to say this is bad, but i really dont like using a database as it is confusing and hard at the same time. I also think storing usernames and passwords in a file is bad, but both the username and password would be encrypted using md5. I dont think this is secure enough though though because im going to make it public. If you could give me tips on how to make this better please tell me.

Also You will only have two attempts per minute ;) Here is my idea: https://drive.google.com/file/d/0B19YDO3uT0ClaVZsYjRFRVZkUzA/view?usp=sharing

Also if you could give me examples on how and where to store the file in the webserver? i am not very good with php to be honest

AntonioSanchez
  • 327
  • 4
  • 14
  • 1
    you do realise md5 is one way? as in .. you can't decrypt it, you can only encrypt 'guesses' and compare the results. and in what way are you going to make it public? :o – Alfie Apr 16 '16 at 02:42
  • I know, Its an app im making. Like an online chat forum. I like that its one way only, Cause from the app, Someone enters their username and password, If it matches both username and password in the file, They can log in!, I have got this all planned out perfectly, I just want to know if it would be safe to do it this way? im guessing no, but id rather not use a database and all that tricky stuff – AntonioSanchez Apr 16 '16 at 02:54
  • I have no quibbles against you storing in a text file, but using md5 isn't a great idea for security reasons (http://security.stackexchange.com/questions/19906/is-md5-considered-insecure). Also, what do you mean by making it public, like you are going to show the encrypted password file? – Jared Drake Apr 16 '16 at 02:54
  • Also it would have a second layer of encryption, possibly SHA512 – AntonioSanchez Apr 16 '16 at 02:55
  • can you describe the process you have in mind in more detail? – Alfie Apr 16 '16 at 02:55
  • Yeah, i edited my post. click on the link – AntonioSanchez Apr 16 '16 at 03:09
  • 3
    Neither MD5 not SHA512 are encryption, they are hash functions. – zaph Apr 16 '16 at 03:12
  • 1
    #iknowiambadatthisstuff #please #help #me – AntonioSanchez Apr 16 '16 at 03:13
  • 3
    #knowthatinternethasmuchinformation. – zaph Apr 16 '16 at 04:01
  • So, in the folder that contains all the usernames and passwords would it be a good idea to put a .htaccess file with "deny from all" inside it? So far ive tested it and it will not let me in the folder to view the files (from the web browser that is) – AntonioSanchez Apr 16 '16 at 04:10
  • Do not put the file in the html directory structure, place it above the html directory structure where it can't be accessed from the web.. There is no need to allow web access to the file. – zaph Apr 16 '16 at 04:22
  • Unless this is a toy get help from a cryptographic domain expert. Keep in mind that it only takes one mistake in the security to allow an attacker access. Finally: Use 2-factor admin access to the web server and off site backups. – zaph Apr 16 '16 at 04:26
  • I cant move it above the default directory, im using an online web hosting service. it wont let me... ugh – AntonioSanchez Apr 16 '16 at 04:32
  • 1
    *"but i really dont like using a database as it is confusing and hard at the same time."* This is a fundamental admission of your unwillingness to learn how to use the appropriate tool for the job. Yes, this is bad. – Michael - sqlbot Apr 16 '16 at 07:55
  • is really? im not into php and i dont want to spend a year or something learning that to do something very simple, im not talking about making something as powerful as facebook – AntonioSanchez Apr 17 '16 at 06:40
  • Get a better web hosting service that allows for a directory outside the html root. – zaph Apr 17 '16 at 14:52
  • WRT simple: cryptographic security is not simple to get right. If it is wrong it is just an illusion. – zaph Apr 17 '16 at 14:54
  • @zaph yeah i can make folders outside the public html directory, just had to tick an option – AntonioSanchez Apr 18 '16 at 00:50
  • okay yeah, im going to learn how to actually make a secure database and store the usernames and passwords in. My brother gave me a book that can help me – AntonioSanchez Apr 18 '16 at 07:41

3 Answers3

2

Most databases can be accessed from the open web and you have to store the database password in a PHP file as well. Therefore in most configurations there is no security benefit using a database. It is just a more comfortable handling.

Hashing passwords is always a good idea and should be taken for granted. md5 is not a secure algorithm. Consider usage of password_hash() instead. Don't forget to intersperse a salt string to prevent rainbow table attacs when your hashfile gets stolen.

Any two-way-encryption would make your system insecure at all, because you would have to hold the secrets for decryption into plain text on the server an an attacker could steal everything he needs.

Limiting the login attemps is certainly not a bad idea, however, it is not as essential as you think. The main weak point is to get read access to the hashfile and then process an offline bruteforce, preferably with rainbow tables.

Pinke Helga
  • 6,378
  • 2
  • 22
  • 42
  • Thats nice to hear, managing databases is a hassle for me. Could you like, Give me a basic idea of how i should store them? – AntonioSanchez Apr 16 '16 at 03:17
  • 2
    Use SSL to secure the transmission. There are also free providers of certs. Serverside hashing passwords is strongly recommended. Clientside hashing as your diagram illustrates would be senseless. You can just use csv or any other format to store your data. There are PHP function to handle such files. To improve security you could use .php extension nevertheless. Take a look at managing .htaccess as well. Managing a single database table with SQL is really simple. Even a JOIN of more tables isn't too hard. I encourage you to get familiar with simple database commands. – Pinke Helga Apr 16 '16 at 03:53
0

Here's what I would suggest. Don't use md5 because it's insecure and too fast without using iterations.

You really must have an SSL certificate for this to be secure from people seeing the password. Anything without a certificate is roughly equivalent to the user sending a raw text password. You have basically just changed what their password is.

As zaph noted, it's best practice to pin the certificate

On the client

  • send the password to the web server (encrypted by the certificate for you)

On the web server

Community
  • 1
  • 1
Jared Drake
  • 124
  • 7
0

You need to use a password hashing algorithm that also takes a salt and iterates such that the hashing takes substantial time such as 100ms. Typically you can use algorithms such as PDKDF2, bcrypt, script or password_hash.

The password must be hashed on the server.

Use HTTPS for communication the password and pin the server certificate in the app, the pinning is important as it will protect against MITM attacks.

A DB may not be necessary, it is an issue of lookup time and disk I/O. You can start with a flat fine and migrate to a DB if/when the performance is needed. "Uncle Bob" Martin delayed using a DB in FitNesse and in the end found a flat-file solution was all that was needed.

Note: Essentially all simple hash methods such as SHA2, SHA3, etc. are to fast and need many iterations to increase the calculation time. The time is important so an attacker can not try hashed quickly. A random (not exactly unique) salt per password is needed to eliminate the use of rainbow tables of pre-calculated hashes.

zaph
  • 111,848
  • 21
  • 189
  • 228