Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 7 years ago.
Improve this question
I need to prevent reuse of password hash by another user,
for example if a user can create his hash (knowing the password of curse)
if he gained access to the database and replace someone else's hash with his, he will be able to log in as that user
I was wondering if adding the id of the user to the hash will be good practice, if not, what else can I do?
thank you.
If someone can substitute the credentials in your database, and if this is the only thing that determines access to your system, then, yes, the user can cause your system to accept whatever password he chooses.
This is one important reason why many production systems ... used within a company ... and many of the back-side "plumbing" layers of public-facing systems ... do not use passwords of any sort to handle authentication or authorization. Instead, they use "trusted third-party authority" techniques such as LDAP (OpenDirectory) or Kerberos. No one is "whispering magic-words to one another" at any point.
In this scenario, both "authentication" (verifying who the requesting user actually is), and "authorization" (establishing what he can do) are not handled by logic within the systems themselves: these tasks are delegated to a centrally managed corporate authority. There is the concept of a "single sign-on." There are no "passwords" to steal. Even if the system requires the user to respond to a personal-challenge, e.g. to enter a password as part of the procedure, the central authority (software layer) manages everything: providing the challenge, interpreting the response, knowing that a correct response was timely given, and so forth.
These are robust technologies with peer-reviewed, trustworthy implementations that are also cross-platform and industry standard. They're very comprehensive. When you "swipe your badge" to get into your building every morning, they're probably what actually unlocks the door. They can be accessed by PHP, and/or by whatever web-server service is running your PHP application.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
I am building a system to store survey data where one of the requirements is that if a hacker gets access to the web server, they are not able to view any of the data. But, the web application does need to be able to decrypt the data and display it (for instance an authenticated user might need to see a table containing survey responses in plain text).
I am having trouble figuring out how the web server could decrypt data without a hacker also being able to do it. Obviously if the decryption key is stored on the server access to the server also entails access to the decryption key.
The only thing I can think of so far is to distribute a decryption key to the users, have them enter it as part of the authentication process, store it in a cookie, and then submit the key with every web request so that it's never stored on the server and instead only in memory for limited periods of time. Obviously this would be served over HTTPS so that the key is also encrypted at transmission time.
I have never seen a system that requires a private key as part of the authentication process, so I'm assuming there is a much better way to do this.
While this is more of a theoretical question, the application will be written in PHP, likely using the Laravel framework, hosted on an Ubuntu server.
You're trying to solve a very hard problem, but here are some pointers if you dare go this direction:
MIT's Mylar was a recent breakthrough trying to provide a practical solution to this problem (in contrast to impractical homomorphic encryption), but it seems to have some security flaws. Nevertheless, it is the right direction to be looking for a practical solution.
There is a concept known as a zero knowledge web application, sometimes called "no knowledge", which keeps cryptographic keys on the client side and performs all encryption/decryption on the client side. Without endorsing a product, it is informative to look at SpiderOak as an example. However, be wary that if you are doing the encryption in JavaScript, then a hacker who gets access to your server can replace your JavaScript with their malicious JavaScript. How to deal with this? Look at Mylar.
EDIT:
The problem with your requirements is that a single bad (or negligent) user can break everything (i.e. expose the decrypted data to anybody and everybody). However, if that's something you are willing to live with, there are potential solutions, but they are not easy to implement.
One requirement is that cryptographic computations need to happen on client side, and the key that encrypts data needs to be shared securely between users without exposing it to the web application itself. The most realistic solution to this is having native (thick) clients and avoiding JavaScript cryptography. However, Mylar claims to solve the JavaScript crypto problem.
You will need public key cryptography to have a chance. Users will need to be able to exchange the encryption key with each other, and users need to be able to authenticate other users to prevent a MITM scenario happening from a hacked server.
Generally, I'd say you really have your work cut out for you if you want to attempt to solve this, and you will likely run into many problems. However, the main reason why I am replying is to indicate that in theory, it is not impossible, as shown by recent research in cryptography and web application security.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
when you sign out and then you try to sign in in laravel the inputs(username,password) are empty how to make that the inputs become fill with that username and password when you the last time that you signed in
Although there are ways to do as you wish, this entire process is extremely insecure and I would recommend, no, insist on forgetting this and moving on.
The process of the username and password being automatically entered is something that modern browsers do, mostly. For example, Chrome will remember your username and password if you have told it to do so (It pops up as a bar at the top after signing in if it believes the information should be saved).
Setting this information in a cookie would be insecure for a few reasons, mainly, the information would be readable and could potentially be stolen from the end users machine meaning that a malicious user now has the credentials of the user logging in. Also, if the end user is using a public machine, anyone with access to that machine now has access to the users account.
We don't store passwords in the database as plain text, and that's 100 times more difficult to access compared to a cookie, so why store it in a cookie? Furthermore, an email or a username is equally as dangerous to provide as this information can be used in a variety of ways to gain access to the account or to gain other information from a user.
Let the browser or third party tool of an individual user handle this, having the machine remember them for you and re-enter them, defeats the purpose of the process.
Most modern browsers provide this functionality, so there is no need to implement it in a web app, especially as it is a security risk.
The browser will offer the user the choice to store, or not, and optionally to encrypt the password store to a master password.
You'd need to use cookies. BUT, (and all others WILL agree with me when I tell you) this is a TERRIBLE idea. You'd be echo'ing out in plain text the users password.
Leave it up to the browser the user is using to securely save their password without it being put into the easily readable by anyone at the computer AND any plugin/extension installed.
There's no way to force the browser to autofill, either.
This is how you would use cookies.
This will save the cookie forever, until it's overwritten.
Cookie::forever('key', 'value');
will work or set a $minutes var and use the following
$minutes = 60; // save cookie for 1hr
Cookie::make('key', 'value', $minutes).
Then in your input
<?=Cookie::get('key');?>
I'd HIGHLY recommend looking at the Laravel documentation. It's EXTREMELY clear. As far as any documentation I've read, it's the easiest to understand.
If you use the <?= short tag, ensure that your short tags are enabled in your php.ini otherwise use <?php echo
I'm not sure if Laravel will automatically overwrite.
The problem with storing usernames in cookies, is a problem all cookies have. If you echo the cookie, you'll need to use htmlspecialchars() or htmlentities() otherwise if the cookie had been modified, it could inject script into the page.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I have been reading/googling for the last week on best approach to this issue/application.
I have an app that is bascially a database front end, currently it stores data locally, all works happily (available in the app store).
What i want to do next is store this data on a server.
(Before this i had no experience in server at all so everything from this point on from my own research and asumptions, if something is incorrect please point it out to me).
I decided that a RESTful webservice design would be best for what i wanted.
Basically intention is iPad/Android will be able to talk to web service, web service sits on top of a MySQL database, web service will receive strings, vidoes, photos.
My current situation is i can get the webservice to talk to the MySQL database, i can send simple requests from iPad for data (strings) and to post data (strings), (Still need to figure out best way of handling photos and videos, but thats a different issue).
My Question: What is the best way of making this web service Login/Secure.
The data is sensitive so has to be secure. Currently the user can't access the app without a username & password, but obeviously i need to take precations in the web service also.
I have done loads and loads of googling research and even topics on here i seem to be constantly seeing comments along the lines of "This method is out of date" etc.
It seems to be there are two fundamental approaches,
1) Basically having a GUID which is configered on inital start up <-I think
2) On every request for data also transfering password/username.
Any help guidance would be greatfully recieved.
Thanks
P.S. Sorry about the essay
It is possible to encrypt and sign the data exchanged between the server and the client. For that you can generate your own trusted certificate for free. You'll have to look for the methods based on the technologies you are using. This will protect you against man in the middle attacks as an intruder can't read or alter the data.
Any passwords you use in the code should be encrypted to protect against reverse engineering (at least for amateurs)
Use key based encryption algoritms
Capture all the exceptions, an error should never be transmitted to the client as it's a door to your system.
Protect your wsdl file (if you have any) against public viewing.
Validate your forms, the user shouldn't be able to inject special characters like "<",">","'","=","-"...
This is what I can think of for now.
You can use the following approaches to make your API secure.
oAuth implementation to send and receieve data with authentication headers.
SSL certicificates to make sure the communication between your server and client is encrypted. You can easily buy a private certificate for as low as $15/month.
Hash database fields such as password. (Make sure NOT to use MD5 as it is not secured. Use SHA1 or SHA2 instead).
Don't store user passwords in mobile applications, store some sort of hashed auth key, instead.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
I am developing a web application where users can play a game. If the user wins, she will get money into her account; in the other hand, if the user loses the game, she will lose money as well. I need to store the data "total money earned" and "total money lost" into a Database.
The problem is that, if some malicious user gets access to the database, that user will be able to change all the "total money earned" and "total money lost", and that is a big problem.
At first glance I thought this problem could be totally avoided by encrypting the "total money earned" and "total money lost", but suddenly I realised that this wouldn't work, as this hypothetical malicious user could always change those value to whatever he wants.
This question is not about ""How to avoid users to access my Database"", but rather about "if a malicious user gets access to it, how can I prevent my data to be changed?""
This is just basic server security. If somebody logs into your MySQL database as a user with write privleges there is nothing you can do. You have to stop them beforehand.
Steps you can take:
1) Have strong server passwords and user account design. Don't have people SSH in as root is a no-brainer example.
2) Give your application only as much access to the database as it needs. Don't have your application be allowed to drop tables for instance if it does not need to. This will at least mitigate possible damage.
3) Be sure you are protected against SQL injection. This is probably the number 1 mistake noobies make.
There is of course tons more to know, but there are more books than you can read in a lifetime on the subject of security. I advise you look into one. I highly recommend Essential PHP security for your PHP code. Its small concise and informative.
Starting point:
You could checkout what Magento does with its sales_order table information.
Each row in the sales_order table represents an individual order issued by a customer. There are protection mechanisms in the admin that do not allow admins to edit these orders. You can only cancel the previous and create a new cloned order (if the initial order really needs to be "changed").
At the table level there is a column called protect_code. This code is (i'm speculating) generated as a cryptographic hash (hash_hmac with any one of the algorithms: md5, sha1, sha2, sha256, etc.) of the entire order information object.
If the order information object is hashed using a secure key that the perpetrator does not have access to (for example the hacker has accessed your database but not your PHP code) then he will not be able to alter the values of the order information object because he will also need to update the hash and without using the same secure key he will not be able to obtain the same hash.
You will be able to recognize any row that has been tampered with by recalculating the hash.
Background info:
Normally keys like this are stored in PHP and the hashes are presented to the user within payment forms, to make sure the user cannot change the payment information before sending the form to the payment gateway (a separate website).
Both your PHP application and the payment gateway application share the cryptographic key, because the payment gateway has to hash the data it receives and check that it hasn't been tampered with (by comparing hashes). Usually you receive your (own dedicated) cryptographic key from the payment gateway.
This implies that the user/hacker does not know your cryptographic key and cannot access your PHP server (meaning he can't read the key either).
Anything you use is accessible:
If the user has access to your application server that means he can have access to any and all 3rd party services (secured or not), such as databases, file storage servers, payment services, mail sending services etc.. The only exemption from this rule is if your application server is just an aggregator for other self hosted self contained services.
If the user has access to the database server but not the application server, your cryptographic key should be safe and your data should be hard to tamper with undetected (but not hard to alter or delete).
If you are using a tiny bit of data anywhere in your application an the user/hacker has access to the application server that means that he (the hacker) has access to that data. You can even store the cryptographic keys on a separate server and obtain each of them by request, if the user/hacker has access he can request them too. If your app is using them, your hacker can be using them too.
The first thing you need to understand is that there is no silver bullet with regards to keeping your data secure. From securing access to your server by ensuring only the necessary ports for communication are open to using strong username and passwords to ensuring that the DB user has only the rights required to perform the tasks necessary. It really is a broad topic. I suggest you search the web for OWASP. If an unauthenticated user is able to gain access to your data your encryption is the least of your worries.
For your situation encrypting is fine but consider using a user specific salt and keeping your encryption method safe.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
If I write a login system for a client who later gets hacked can I or my company be held accountable for whatever damages they claim?
Excuse me if this has been asked already. I did a search and found no relavant answers.
I recommend that you consult an attorney for this kind of a legal question. This is a technical forum and not a place for legal advice.
The software warranty and the courts is a murky area. It really would depend on what warranties you provide. Typically with software there is an explicit denial of any warranty and that the software is a best effort however in the US anyone can sue anyone else for almost anything. Just trying to defend a suit can be financially devastating which is why housing contractors have a tendency to have multiple incorporated companies which carry the liability for homes built and insulate the contractors personal assets from any suits.
You do not say what your industry is. Different industries will have different standards. For instance in point of sale there are the PCI standards from VISA, etc. on security standards for card account information.
Depending on the industry and the kind of security breach, yes you could be liable.
You really should get the services of a security specialist and a lawyer in your software target industry to discuss this and other legal questions.
The main point to remember is that when there is a breach especially one with financial repercussions, more than likely your customers will look for someone to blame. So you really want to have something in writing that indicates who is responsible for any liability due to a breach. And as part of that there probably should be some description of what would be considered minimal acceptable security practices on the part of the people using the software.
That said a minimal set of necessary practices that you should follow would be something along the lines of the following. I make no claim these are anywhere complete as I am not well versed in computer security.
Reduce privileges and what can be done as much as possible. This hopefully will reduce the amount of damage that may arise when someone breaches the system.
Always assume that input may be tainted so watch out for standard intrusion practices such as SQL Injection or URL modification in the case of REST or other unexpected modifications to input data.
Never assume that just because something is hidden that it will not be found and exploited.
Log everything possible so that when a breach happens, the forensic team will have the data they will need for an investigation.
Passwords are a fairly poor authentication mechanism so you want to beef them up as much as possible. So password aging is important to force passwords to be changed. Password difficulty checks should be used so as to encourage more complicated passwords that will vary from change to change. Passwords should never be maintained in clear text nor should passwords be transmitted in clear text. Encryption is your friend and helpmate.
Biometric information can make for a better authentication mechanism however some people may have features that do not work well with some types of biometric systems such as people whose fingerprints do not work well. Some type of unique device may also be used such as an authentication code generator that is synchronized to a central device or perhaps a central device which sends an authentication code via a text message to your phone when you attempt to log in.
Using the system probably should require a password to be re-entered at the time of some sensitive action especially with systems which may be accessed from a public terminal.
Make sure that it is easy for someone to log out so that they will be more likely to do so as part of closing out a session.
Make it easy for users to be disabled by a supervisor and provide a way to make it easy for a supervisor to generate a report of who has access to what, when have they used their access, and what did they do when they had access.
Borrow a page from Gmail and other e-mail systems to notify the user whose account it is as well as a manager or supervisor via e-mail any access that seems unusual or of a sensitive nature. Also notify via e-mail if any user account type changes are made such as password change along with logging this type of activity.