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.
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 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.
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 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'm putting together read and write methods to my database and exposing them via URL (I'm using CodeIgniter framework and using URL segments to pass parameters to these methods). The original idea was to have my Ajax script call these methods. However, now I am thinking I could potentially expose these methods to any developer.
What should I do to make sure only authorized developers use my API? I'm thinking they should pass an API key and possibly password to each method call. If I were to provide them with such details, would that be secure enough?
Also, I'm thinking that I should support POST instead of GET as some of the required parameters may not fit in nicely with URL segments. Thoughts?
Implementing OAuth http://oauth.net/documentation/getting-started/ would work for what you're trying to do. I'm not certain of what type of data you're securing, but I agree with TradyBlix this probably best. I've implemented it before, it's not too hard to figure out, it's well documented with many APIs that handle user-data utilizing it.
Another thing you should think about is limiting API Keys to domains, so a developer can only use their API key from their own domain-essentially preventing an unauthorized developer from gaining access, at least without gaining access to an authorized domain and corresponding key.
First: require HTTPS.
HTTPS ensures that a secure channel is established before any request data is sent. Yes, before any request data is sent: URL, headers, cookies, GET or POST parameters... anything. This means that you can use simple methods such as HTTP Basic authentication over HTTPS without putting the user's credentials at risk.
This is really not negotiable, unless the data you are passing over the API is truly public. If you aren't using HTTPS, then any communication with your API (including HTTP Basic credentials) can be sniffed in plain text.
The only reason major sites (like Facebook) don't use HTTPS is because it gets expensive at massive scale.
If you absolutely can't run HTTPS, then you should look into OAuth, which is making strides in API authentication in exactly this situation. With OAuth you can authenticate users while keeping credentials secret over unencrypted channels.
Second: authentication is not authorization.
Don't blindly trust data from authenticated API users. Make sure that the methods and actions they are accessing are appropriate, otherwise you may give your users a backdoor into other users' data or administrative functions.
There's a lot more to it than this, but if you follow these two principles you're on your way.
Maybe you should check out OAuth. It's An open protocol to allow secure API authorization in a simple and standard method from desktop and web applications.
I haven't tried it myself to be honest but it's the first thing I thought of when you mentioned authorized developers use my API. Just an idea.
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'm making a web application and would like to have a secure area where you can only sign in with your finger print. My original idea was to just use a usb barcode reader and you scan that, and it outputs the ID into a text box, but that's not very secure. So I want to use a USB fingerprint reader to maybe generate a hash for each person and store that in a text box instead. Which then will check that against a database with everyone's hash value. Does anyone know if there is a fingerprint reader out there that can do this, or of a way I can easily integrate a reader into a website?
EDIT:
The Idea for this website is that it's like a login system (Sort of like how you can clock in and out if you get paid hourly) The idea is that no one can sign someone else in and out. IF you just use a password, than someone can just tell their friend the password who can type it in. That's why I thought of a fingerprint, or something similar... I'm open to other suggestions
Also, I'm using PHP
EDIT 2: The Basic idea, is I have to come up with a way to Prove someone was there by checking in. I don't want to use passwords, because then someone can just tell someone else their password to type in. Any other suggestions? It doesn't have to be fingerprints.
Biometrics are a very bad way to do authentication for many reasons:
They're essentially just a password that you can never change. (At least not without some serious pain!) With traditional password schemes, if your password gets stolen or guessed, you can at least change it. But if someone steals your fingerprint, now what are you going to do?
Biometrics are not secret. Every time you touch something, you're leaving your password laying around. Every time your picture gets taken your facial image / retinal image gets copied. Passwords have to remain secret to be useful.
Like Borealid said, Biometrics are never scanned exactly the same twice. So when you do matching, there has to be some kind of fudge factor in allowing input. This:
Just makes it easier for attackers to copy your data and replay it, since they don't have to get an exact match. An attacker only has to get close to get accepted.
It forces the authentication server to store the your biometric info in plaintext. You can't hash biometric data like you can passwords, since then you'd have to match exactly with the hashed value.
So don't do it!
You can't do what you want, exactly.
Fingerprints never exactly match. Even if you scan your own right index finger twice in a row, the scans won't be the same. So "hashing the fingerprint" won't work - two hashes of the same finger would be indistinguishable from two hashes of two different fingers (with a good, cryptographically strong hash).
Fingerprint readers work by storing some key onboard, and letting that key out if and only if the fingerprint given is close enough to what they expect. The fingerprint itself is not used to get direct access to anything outside the reader.
Sending the fingerprint as seen by the reader over the network is not acceptable - people are nervous about giving their prints to police. You think they'll be OK giving them to you?
Also not acceptable is having the reader say "finger 2 is OK". This could be easily spoofed.
Instead, have your user use X.509 (SSL) client certificates to access your site. They may, if they wish, control access to their private key via the fingerprint reader.
EDIT: updating this answer. There is, now in the year 2014, a standard from the FIDO Alliance called "UAF" which allows sites to use fingerprint authentication in a way that works across different sites. Rumor has it Paypal is going to begin using it soon.
Biometry for remote authentication is never secure. You can't know if a real finger with that fingerprint is in a reader, or if the user only sends you an image. So a fingerprint just becomes a password the user can never change, which is the same for every service you login to, and which is left on every object the user touches.
Biometry can only work for local authentication where you trust the reader to be not hacked(i.e. you have physical control over the reader) and the reader can distinguish a real finger/eye/... from a fake one. Which most can't.
It is possible to create a one way hash of a finger print. You first have to extract a number of observables just like you might do for a fuzzy match. But since you need an exact match for a hash you need to throw error codes at the values you extracted which then can correct the minor differences on each measurement. It's not easy to code and it doesn't fix the fundamental problems listed above, but it should be possible.
So you want to use a local authentication mechanism to authenticate a remote resource? There are many issues here to suggest this would not be a smart choice. E.g., how does the web app know the hash belongs to the original user and not someone who has a duplicate?
What I would suggest instead is to go the route of banks from several years ago when they had smartcard readers sent to credit card customers. Use the fingerprint scanner to store a local copy of the user's login name, requiring a second form of authentication such as a password.
This is so bogus. Why can't you encrypt a fingerprint? Your master is stored encrypted, you send an encrypted one to the server. The server software un-encrypts both and does the comparison. Simple. Your 'expert' solutions are bogus.
why not use face match software for authentication.
http://www.oculislabs.com/products/privateeye