Is there a way to authenticate to a website using fingerprints?
I was thinking of the following scenario.
The server has ISO 19794-2 fingerprint templates of all valid users.
Client machine has a fingerprint scanner.
Client opens website on browser
Browser has Java Applet/ActiveX control/HTML5 object gets fingerprint template from the scanner & sends to website.
Website allows/disallows based on fingerprint.
However, this seems very insecure. It's not difficult to get a jpg of someone elses fingerprint and convert it into ISO 19794-2 template of the same. Then programmatic-ally one can login to the website by sending the userid & template to the website.
Is there a secure algorithm/design for allowing people to login to a website using fingerprints?
It's an issue of a Trusted path between fingreprint scanner, and your website's verification logic. If someone could disguise as a valid client and submit login requests to your application, your scheme would be broken.
I think the best you can do is to use two factor authentication, I would request a users password, and provide it as input to some PKDF, and encrypt login request with it, this way if someone get's users fingerprint, he won't be able to forge a login request without knowing users password. Besides, biometric is mostly done as additional authentication factor, not the only one.
If you don't wan't to do this, you could obfuscate application code, issue it with one time key, which would be valid for very short time, to minimize risk of reverse engineering, and sign request with this key, but it's not very secure, it requires a lot of husstle without any significant security increase.
Reading fingerprint and authenticating from client-side is very much possible. But this has to be supported by the manufacturer of the scanner. The link: http://camsunit.com/application/javascript-based-fingerprint-scanner-for-website-authentication-and-attendance.html shares the javascript API for communicating with the fingerprint scanner. One of the operations is CaptureAndVerify which validates the encrypted existing template with newly captured one and passes the response to the server directly, with ensuring the authentication shall be done securely.
Related
On webpage (with https)
Client connects to server with websocket (secure wss over TSL)
Server send 'ready-for-user-and-password'-message
User enters info and Client sends it
Server validates and as long as websocket is connected, knows who the recipient is
EDIT:
I am considering the above instead of using a post method.
It can be safe against some attacks but as usual, there are ways to break into the site and we have to evaluate security holistically
DB passwords
It is not clear from the description but plausible that the setup you've described stores user passwords in plain text.
Best practice in that respect is to calculate password's hash sum with salt and keep that in the database, so if attacker manages to get a db dump, they will need a lot of time to guess a password based on that.
Rate limiting
You should limit unsuccessful login attempts so the attacker won't be able to easily pick a password by bruteforce.
Logging
Another thing which can be problematic here is logging: you need to make sure the credentials don't end up on application log files (I've seen that with credit card numbers).
Similar concern is retaining the sensitive info for too long after verification has ended which makes them more vulnerable (to e.g. forcing a heap dump in Java and picking them from that file)
SSL secret material
If you don't pay enough attention to reducing the access to ssl private key, somebody can play a man-in-the-middle attack.
Depending on the ciphersuites your app server supports, previously recorded communications can be vulnerable to decryption if an attacker steals the key. The concept of resistance to that is called forward secrecy. You can validate if you properly tuned your web app here.
Your cert authority (or any other else) can issue a certificate for your website to somebody else allowing the attacker to misrepresent you (see Mozilla and WoSign, Additional Domain Errors).
CORS
You should also set the Content-Security-Policy so that it will be trickier to force the browser code to send this auth info to other servers.
Social Engineering
Attacker can trick your user into launching some code in the web tools console - you can try opening a web console e.g. on Facebook and see what they've done against that.
New stuff
Vulnerabilities get discovered each day, some of them are published on bulletins, you should follow those for your stack (e.g. OpenSSL) and patch / upgrade where appropriate.
I am asking myself. What is the best way to send personal information from your iOS device to the server.
At this moment I encrypt the password in the app ( sha1 salt password pepper ) then I send post data using from iOS to the server.
What is the best way to protect the user and secure for any MITM attacks. Is my way secure enough?
UPDATE:
I added the SSL certificate. To make sure the user only has to login once I store a key generated when the user registered. I fetch them when the user logins for the first time. In oombination with the username and user id. Is this a good way? Only jailbroken users can read it and have risk.
Hashing the password on the client side will help prevent the password itself from being detected in eavesdropping, but it really doesn't provide any security on its own, as the credential then becomes the hashed version of the password, not the original password itself. An eavesdropper could just grab the hashed version, and then send the hash themselves.
By far the easiest solution is to simply use SSL/TLS. Since you mentioned 'post', that means you're probably using HTTP. Instead, you could just connect via HTTPS and post the data, exactly the same as you're doing already. Long as the certificate is checked for validity (I believe the iOS framework already does such by default), then the connection should be largely secured.
That should be good enough for most situations. There are some more complicated and involved techniques you can use to harden further, but SSL/TLS does a massive amount on its own.
I am implementing an app where I don't have a system requiring username and password. What I do require is a name and a phone number.
The scenario is like this:
1) user opens the app for the first time
2)app makes a request to my server and gets a unique UserKey
3)from now one any request the app makes to my REST service also has a signature. The signature is actually a SHA(UserKey:the data provided in the request Base64Encoded)
4)The server also performs the same hash to check the signature
Why I don't use SSH:
not willing to pay for the certificate
I don't need to send sensitive data like passwords, so I don't see the benefit of using it
I just need a simple way to call my own WCF REST services from own app
I understand that there is a flow of security at step2 when the UserKey comes in cleartext, but this happens only once when the app is first opened. How dangerous do you think this is?
What would you recommend? Is there any .NET library that could help me?
Actually, there are several problems with that approach. Suppose there's man-in-the-middle whenever you make a request to the server. By analyzing, for example, 100 sent packets he would recognize similar pattern with signature in your requests. Then he would forge his own request and add your signature. The server checks the hash - everything's alright, it's you and your unique user key. But it's not.
There's a notion of asymmetric keys in cryptography which currently is really popular and provides tough security service. Main concept is the following: server generates two keys - public and private; public key is used to encode texts; they can be decoded only with the use of private key, which is kept by the server in secure location. So server gives client the public key to encode his messages. It may be made double: client generates public key and gives it to the server. Then server generates keys and gives encoded with client's public key his own public key. This way it's almost impossible for man-in-the-middle to make an attack.
Better yet, since the problem is really common, you could use OAuth to authorize users on your website. It is secure, widely used (facebook, g+, twitter, you name them) and has implementations already in variety of languages.
Since you control both the application itself and the webservices, you can do this with SSL (which gets rid of the problems with your current approach) without paying for anything. You can create a self-signed certificate and install that on your webserver; configure the SSL context of your client application to only trust that one certificate. Then, create a client-side self-signed certificate and install that within your application. Set the server up to require mutually-authenticated SSL and only allow your self-signed certificate for access.
Done. You client will only talk to your legitimate server (so no one can spoof your server and trick the client in to talking to it) and your server will only talk to your legitimate clients (so no one can steal information, ID, etc). And it's all protected with the strong cryptography used within SSL.
I want to be able to set up a web application to automatically (i.e. on a cron run) send a POST request to a remote website. The remote website requires a username/password combination to be sent as part of the POST data. I want the web application to be able to make the POST requests of the remote website without requiring the user to provide the password to be sent with the POST data, each time the request is made.
It seems to me that the only way to do this is to store passwords directly in the database, so that the cron run can execute a POST request that includes the password as part of its POST data. Without storing the password in some form in the database, it seems it would be impossible to provide it in the POST data, unless the user provides it each time the request is made.
Question 1: Am I mistaken and somehow overlooking something logical?
Question 2: Assuming I have to store the passwords in the database, what is the safest procedure for doing so? (MD5 and similar one-way encryption clearly will not work because I have to send an unencrypted password in the POST request.)
Thank you for your help!
a. if you don't know the password... you can't authenticate, that's the idea of a password !
b. if you need to know the password - you need to save it in a decryptable way - hence - less secured.
c. if you own the site, you can use a cookie with a very long timeout value, but - you still need to authenticate at least once.
d. unless you're guarding money / rocket science, you need to encrypt the password and store it in the DB and decrypt it every time before use, at least you are guarded from DB theft.
e. make sure you're authenticating over secure channel (as https) so the password will no be sent as clear text.
One good solution is probably to use SSL (i.e. HTTPS). You can create a certificate authority on the server side, then have this certificate authority sign a client certificate that you generate. Make sure the HTTP server is configured to trust the newly created certificate authority.
Once this is done, you should install the certificate on the client side. The client must present the certificate when talking to the HTTP server. You have to configure the HTTP server to require a trusted certificate when POSTing to your secure URLs.
Awesome example of how to do this with Apache HTTPD is posted right here!
The document I linked doesn't describe how to set up the certificate authority and create self-signed certificates, but there are tons of examples out there, for example here.
This is a good solution because:
no passwords are stored in the clear
if the private key of the client's certificate is stolen or compromised, you can revoke it on the server side
The key here is that the client is providing its credentials to the server, which is the opposite of what is usually done in a browser context. You can also have the client trust your newly created certificate authority so that it knows it's talking to the right server and not a man in the middle.
Given that you have to send the password in clear-text and do it repeatedly without user-interaction you'll need to store and retrieve the same from a data-store (file/database/memory).
What you really need to consider is the last-line-of-security of the password store.
Whether you encrypt it or not doesn't matter. The person/program with access to the data or the cipher key will be able to read that password.
Sort this issue out, document it - (this becomes your security policy for the app) and then implement it.
Security is only a level of difficulty you implement to lessen a risk.
Fortunately, Tumblr now implements OAuth, which solves this problem.
I have a website that requires a user to authenticate themselves with a user name and password. I would like to use SSL, but I don't have an SSL certificate. But I do something else that I think is okay.
My site is primarily AJAX based and requires JavaScript, otherwise nothing will work.
When the user tries to login, I query the database using AJAX to look for a salt for that user name, if none is found a random salt is returned (to keep people from knowing if there is a user with that user name or not). Then, using a MD5 function for JavaScript, I hash and salt the password 4K times (like Linux does when it uses MD5 for it's password hashing) client side, then I pass that hash to the server in plain text. This hash will then be hashed a few more times and presented to be checked with what's in the database.
Is this secure? If not, how can I secure it without forking over the cash for an SSL cert for a mostly internal website?
No. It's not secure. A man-in-the-middle can snoop the hashed value and present it to you later, falsely authenticating himself.
To authenticate someone, you have to prove that they know a secret. Anything passed over an unencrypted channel is not a secret.
Use SSL. You can get certificates for free that are accepted by Firefox, and you can give IE users instructions for adding a new CA to their trusted roots. Certificates that are accepted by all browsers out of the box are cheap, I think $30 per year.
The best options are:
Use a certificate signed by StartCom (free). Supported natively by recent versions of Firefox and Safari. Users with IE can add the CA to their list of trusted roots.
Use a self-signed certificate and distribute it to your users to add in their browsers.
As others mention, your solution is not secure. It offers no improvement over sending the password in cleartext to the server. The major reasons:
Anything sent from the client in clear text and directly used to authenticate will be susceptible to man-in-the-middle and eavesdropping attacks. In your suggested solution, if you know the hashed password, you can log in. Sending the password as a hash makes no difference.
After authenticating, the data is still sent in plaintext, so it is easy to sniff.
MD5 is full of holes
You could make your own SSL certificate for free, it wouldn't be trusted by general users but you can trust it.
By using JavaScript and a transport layer that is not encrypt, you open the possibility of someone grabbing that hash you send to your server, not to mention give an exact blueprint of how you are hashing the password/username.
It really depends on how important security is for that application. If it is very important drop the Ajax, and pick up a SSL certificate and use the HTTPS layer.
Your solution is open to replay attacks. Try Digest Authentication (RFC 2617) directly between the browser and web server.