What are the vulnerabilities of utilizing file systems instead of SQLite?
-
I have a domain address and host I don't want to have a site and I just want to have a server to put some data there There are 1 - public-html folder where the index of a site could be placed in 2 - non public-html folder where the important files from security point of view are placed in I put the data in non public-html In public-html, I just put a php file called file1 which includes another php file called file2 which is placed in non public-html file2 is responsible for uploads of the data to the non public-html and also some images and json files in public-html folder But I don't want to have any index file that a site needs Regarding security issues on server, what are the vulnerabilities of utilizing this type of file system instead of SQLite? Do I use SQLite or I use encrypted json files in non public-html place of the server? In other words, can I forget SQlite and use this type of file system management or it is dangerous or unsafe compared to SQLite for any reason ? Example: Imagine I want to register username and passwords of some users User name is phone number of the user I can create the following folders to register or retrieve the username and password of the users quickly: 1 - folder of international code 2 - folder of the first 3 digit 3 - folder of the next 2 digit 4 - the json file which the phone number is registered there for example if the phone number is +518203040, we have the following folders: 1 - 51 2 - 820 3 - 30 4 - file1.json which the phone number is registered in for encryption I totally make a different and vague json file which is not readable except that you have the key for decryption Thanks in advance
-
I have a domain address and host I don't want to have a site and I just want to have a server to put some data there There are 1 - public-html folder where the index of a site could be placed in 2 - non public-html folder where the important files from security point of view are placed in I put the data in non public-html In public-html, I just put a php file called file1 which includes another php file called file2 which is placed in non public-html file2 is responsible for uploads of the data to the non public-html and also some images and json files in public-html folder But I don't want to have any index file that a site needs Regarding security issues on server, what are the vulnerabilities of utilizing this type of file system instead of SQLite? Do I use SQLite or I use encrypted json files in non public-html place of the server? In other words, can I forget SQlite and use this type of file system management or it is dangerous or unsafe compared to SQLite for any reason ? Example: Imagine I want to register username and passwords of some users User name is phone number of the user I can create the following folders to register or retrieve the username and password of the users quickly: 1 - folder of international code 2 - folder of the first 3 digit 3 - folder of the next 2 digit 4 - the json file which the phone number is registered there for example if the phone number is +518203040, we have the following folders: 1 - 51 2 - 820 3 - 30 4 - file1.json which the phone number is registered in for encryption I totally make a different and vague json file which is not readable except that you have the key for decryption Thanks in advance
First point, do not use encryption for passwords, it is potentially insecure. Use proper hashing as described in Secure Password Authentication Explained Simply[^]. If you do it properly then you can store it in SQLite, or any other type of database.
-
First point, do not use encryption for passwords, it is potentially insecure. Use proper hashing as described in Secure Password Authentication Explained Simply[^]. If you do it properly then you can store it in SQLite, or any other type of database.
Thank for the article I read the article but I still don't get from security point of view why a hash and salt should be created and saved beside password It seems in this way we can ask user to enter any letter of interest as article specifies From security point of view it seems useless I mean an attacker just attempts to send username and password just like the original user who has forgotten his/her password Can you please explain that for me?
-
Thank for the article I read the article but I still don't get from security point of view why a hash and salt should be created and saved beside password It seems in this way we can ask user to enter any letter of interest as article specifies From security point of view it seems useless I mean an attacker just attempts to send username and password just like the original user who has forgotten his/her password Can you please explain that for me?
You do not save the hash beside the password. The key to password security is that you never store passwords, either in clear text or encrypted. Both types can be hacked. You create a hash from a salt value and the password, and store the hash value in the database. When someone enters their password to login you recreate the hash from the entered password and saved salt value and compare with the stored hash. Hash values cannot (in general) be used to recreate the original data so are the most secure types for security.
-
You do not save the hash beside the password. The key to password security is that you never store passwords, either in clear text or encrypted. Both types can be hacked. You create a hash from a salt value and the password, and store the hash value in the database. When someone enters their password to login you recreate the hash from the entered password and saved salt value and compare with the stored hash. Hash values cannot (in general) be used to recreate the original data so are the most secure types for security.
Ok thanks, I got the point In fact, It is not for protecting the database against brute force attack but It is protecting some other attacks If somehow attacker reaches to the database, he/she can't access the passwords I'm too worried about attacks, can I trust the server administrator for not deleting or editing a file from the server ?
-
Ok thanks, I got the point In fact, It is not for protecting the database against brute force attack but It is protecting some other attacks If somehow attacker reaches to the database, he/she can't access the passwords I'm too worried about attacks, can I trust the server administrator for not deleting or editing a file from the server ?
-
AndroidVH wrote:
can I trust the server administrator
We could not possibly answer that. You need to check what service they are providing, and what guarantees they make.