For a webapplication, when HTTPS is not available as a security measure, is it possible to still make the login somewhat secure? E.g.:
Tokenize logins, to make repeat attacks difficult?
Somehow encrypt the sent password from a HTML password field?
In particular I'm using CakePHP and an AJAX POST call to trigger authentication (includes provided username and password).
Update on the problem:
HTTPS is not available. Period. If you don't like the the situation, consider it a theoretical question.
There are no explicit requirements, you have whatever HTTP, PHP and a browser (cookies, JavaScript etc.) offers in real life (no magic RSA binaries, PGP plugins).
Question is, what is the best, you can make out of this situation, that is better than sending the passwords plaintext. Knowing the drawbacks of each such solutions is a plus.
Any improvement better than plain passwords is welcome. We do not aim for a 100% l33tG0Dhx0r-proff solution. Difficult to crack is better than complicated to hack which is better than a trivial sniffing revealing the password.
It is a bad engineering practice to reinvent the wheel. Engineers who do this are falling victim to the "Not Invented Here" bias, which can cause a lot of damage when it is a security critical system.
SSL/TLS which is behind HTTPS is absolutely vital in maintaining a secure connection between a website and a browser. Public wifi networks put users at risk, and when used correctly, HTTPS is the only tool that can protect user accounts from this vulnerability.
In the case of two clients that need secure end-to-end (e2e) encryption then there is the open source and vetted Signal Protocol which has received number opens source ports on github and a wide adoption from popular apps like WhatsApp. There is no need to brew your own, these protocols work well for a reason.
If your host doesn't support HTTPS then a service like Cloudflare Universal SSL can be used to ensure all browsers connect to your site using HTTPS, even if your server doesn't support SSL/TLS. The connection between Cloudflare and your website will still be unprotected, but this Cloudflare service is intended to protect users against threats found on public wifi networks. From the perspective of a penetration tester, not providing HTTPS is highly suspect, if you aren't providing a basic security requirement as delivering traffic, then what other security requirements are you missing? HTTPS certificates can be obtained for free using Let's Encrypt or Start SSL, there is no legitimate reason not to support HTTPS.
HTTPS is vital because it does lot more than just "encrypt passwords". Another important role is that it should prevent the user from giving logging into a malicious server that is impersonating a real server. Using a system to protect the password alone is still a violation of OWASP A9 - Insufficient Transport Layer Protection because you would still be transmitting session credentials in plain text which is all the attacker needs (Firesheep).
JavaScript-based cryptography cannot be used to construct a secure transport layer.
"Tokenize logins": If an attacker is sniffing
the traffic, they'll have the plain text username/password and then
they can just login with these new credentials. (Replay attack)
"Somehow encrypt the transmitted password": After the person has logged in
an attacker can sniff the traffic to get the valid session id
(cookie) and then just use this instead of logging in. If the
entire session was protected with SSL/TLS then this is not a problem.
There are other more complex attacks that affect both this system and our current SSL infrastructure. The SSLStrip attack goes into greater detail. I highly recommend watching Moxie Marlinspike's Blackhat 2009 talk, which lead to the HTTP-Strict-Transport-Security standard.
Since you cannot do SSL at the web server, and you are not a security expert, look for an existing secure authentication service that you can utilize, and let them handle both the SSL and the complexities of handling credentials for you.
In particular, I would suggest that you use a free third-party authentication service, such as OpenID. They have libraries for PHP including one for CakePHP.
Edit: (about risks)
While using a 3rd-party secure authentication service (that uses HTTPS itself) can mitigate the problem doing authentication itself without using HTTPS (on your server), it does not entirely eliminate the possibility of attacks.
The most common two attacks would be replay attacks, and session-hijacking where the attacker is able to either re-uses a genuine login session token later, or use a valid session token for their own malicious purpose.
The replay attack can be mitigated by having the session token expiry, and preferably by using a nonce to prevent session replay and to reduces the risk of session hijacking. With a nonce, a legitimate session generates an error if successfully hijacked, because the nonce has expired (been used), so their own session is no longer valid.
If you cannot use HTTPS to encrypt the session token while being transmitted to and from your server, you cannot entirely prevent active attacks such as session-hijacking or man-in-the-middle attack. This may be acceptable in some cases, such as websites with a small user base for non-commercial usage.
The short answer is that without SSL endpoint to endpoint encryption, it's impossible to do it securely...
One of the primary reasons for this is that you can't do secure crypto in a browser. See this reference - Javascript Cryptography Considered Harmful.
Additionally, there's no way that you can be sure that the source of the credentials are indeed who you're talking to. Meaning that there's absolutely no way without SSL to be sure that there's not a Man-In-The-Middle Attack going on.
So no, you can't do it.
Additionally, don't even try. Get SSL. You can get free certificates. Hosts will usually give you a dedicated IP for a few $$$ per month. And if you really care about security, you'd be using at least a VM with a dedicated IP address anyway.
To even attempt this would be Security Through Obscurity at best, and nothing at worst. SSL is a solved problem. Why not use that solution. Security is not something to guess at. Use the proper techniques. Don't try to invent your own. It won't work...
As you suggested, you may be able to generate a unique token each time the page is created. That same token would need to be sent back with the form data and could not be reused. You could also keep the password safe by using JavaScript to hash it, if you can rely on it being enabled by your users.
This scheme is still not secure, however. An attacker could still see everything going across the wire. They could intercept the token and send a response back to you before the user does. Or they could just wait for someone to login, steal that person's credentials (as they are sent over the wire), and just make their own login request later on.
Bottom Line - you need to use HTTPS to guarantee the site is secure.
You can encrypt the password using Javascript and decrypt it on the server.
I would recommend generating an RSA keypair on the server, send the public key along with a timed salt to the browser, then encrypting the password, combined with the salt, using the public key in Javascript.
You can find an RSA implementation in Javascript here
You should include both the IP address and the entire X-FORWARDED-FOR hedaer in the authentication cookies to prevent cookie theft behind proxies.
If you're dealing with sensitive data, you could generate a random AES key in Javascript, then send it to the server along with the password encrypted with RSA.
You could then make the entire application use encrypted AJAX requests from a single page and not use an auth cookie at all.
Note that it is not possible to protect against an active man-in-the-middle attack without SSL. An active attacker can completely replace your site with his own proxy, and there isn't any way to defend against that. (Since there cannot be any known good code)
You can use HTTP Digest authentication, which is supported by most browsers and does not send the password in clear over the wire.
The downside is the ugly log in box displayed by broswer. If you preffer to stick with forms, then you can implement exactly the same protocol as HTTP Digest in your forms authnetication: send hidden fields containing the realm and the challenge, and have the client add in JavaScript the nonce and compute the digest. This way you'll use a well known and proven exhange protocol, rather than roll your own.
HTTP Digest requires only hash operations.
Create a public/private key pair using an asymmetric cipher.
Create a symmetric key on the server.
Send the public key down to the client side.
Create a random key for the symmetric cipher client side.
Encrypt that random key using the public key client side.
Send the encrypted key to the server.
Server does the following:
a. Decrypts the random symmetric key using the private key.
b. Creates a token containing the generated client key.
c. Signs the token.
d. Encrypts the token using the server symmetric key.
e. Encrypts the already encrypted token with the client generated key.
f. Sends the encrypted token down.
The client receives this token and does the following:
a. Decrypts the token with the key it generated.
b. Stores the decrypted token.
c. At this point the stored token is only encrypted with the server symmetric key.
On every from the client to the server:
a. Encrypt the outbound data using the client generated key.
b. Send the token + encrypted data
On every request the server receives:
a. Decrypt the token using the server symmetric key.
b. Verify the signature.
c. Decrypt the data using the client generated key stored in the token.
What about HTTP Digest Authentication? It provides security by MD5-hashing username, password and a nonce (among other things) before sending it to the server. MD5 isn't really secure, but it's a good way for simple security with HTTP.
Of course this doesn't prevent hackers from changing the message... but it secures your password.
HTTPS has numerous use cases, most of which are designed to defend against Man-in-the-middle attacks. Anyone with a hacker's mindset will shudder to tell you that there is no way other than the established way to accomplish something. The fact is that just because you use TLS (the standard which modern HTTPS uses), does not mean you are using it well. Additionally, just using TLS does not prevent someone from exploiting known weaknesses. Just as you may be finding creative ways to secure your data, there are people who are finding creative ways to exploit your security measures.
So, what to do?
First of all, if you're going to forego TLS, it is helpful to understand how it works. And it is all about a handshake.
Once the client and server have agreed to use TLS, they negotiate a
stateful connection by using a handshaking procedure.[7] During this
handshake, the client and server agree on various parameters used to
establish the connection's security:
The handshake begins when a client connects to a TLS-enabled server
requesting a secure connection and presents a list of supported cipher
suites (ciphers and hash functions).
From this list, the server picks
a cipher and hash function that it also supports and notifies the
client of the decision.
The server sends back its identification in
the form of a digital certificate.[contradiction] The certificate
usually contains the server name, the trusted certificate authority
(CA) and the server's public encryption key.
The client may contact
the server that issued the certificate (the trusted CA as above) and
confirm the validity of the certificate before proceeding.
In order to
generate the session keys used for the secure connection, the client
encrypts a random number with the server's public key and sends the
result to the server. Only the server should be able to decrypt it,
with its private key.
From the random number, both parties generate
key material for encryption and decryption.[contradiction] This
concludes the handshake and begins the secured connection, which is
encrypted and decrypted with the key material until the connection
closes.
If any one of the above steps fails, the TLS handshake fails, and the
connection is not created.
Source: Wikipedia
So, is it possible? Yes. I was taught that anything is possible. It may be expensive, but it is always possible.
I want to fully disclose that I am NOT a security professional, just an enthusiast. I do not recommend attempting this for a production-grade project or anything other than your own edification. You should DEFINITELY check out this SO post which provides an excellent explanation as to roadblocks in setting up your own security protocol.
However, if you want to move on, here are some thoughts that come to mind. These are realities that will exist regardless of which direct you went with this project.
HTTPS is supported by all major modern browsers. Even with this reality, HTTPS load times are slower than plain HTTP. Without extensive production, it is highly likely your alternative implementation will be a fraction as secure while being significantly slower. This will be a drawback of any homegrown implementation unless you are utilizing browser features, which brings us full circle back to using TLS, which is what modern HTTPS utilizes.
If you manage to encrypt your password without TLS on the browser side using Javascript in an unpredictable enough fashion that an MiTM attack would be difficult, don't rest there. You also should be securing the data you send back and forth. Otherwise the password being encrypted really is irrelevant. Sure, an attacker might not know bobsmith109's password, but he doesn't need it, because he can sniff every single activity on the network. He knows what times bobsmith109 logs in, can probably trace his IP, and any other sensitive piece of data you send back and forth.
No matter what security measures you take, there is security in depth. So one thing that you can do right off the bat is make sure you encrypt your data in the database while also requiring strong passwords.
I reiterate that I am not a security professional and strongly discourage this as anything other than to satiate your curiosity. It is astronomically improbable that you can create a viable alternative to TLS without an extraordinarily large group of security professionals contributing to a project for years if not decades, which is what SSL/TLS can boast. That being said, a good starting point if you choose to go forward is to look at the handshake model above and see how you can implement a version of this without TLS.
I would be remiss to not share in my post that most real-life barriers to using HTTPS are being actively fought against. One of the largest - cost - is very close to becoming a non-issue. A free certificate authority will be coming out 2Q 2015 is supported by some big guns, including Mozilla and Akamai, to name a few. Here is an article.
Login without HTTPS, how to secure?
Since there is no secure channel between your server and your client:
because there is no secure channel, anybody can snoop your traffic.
because anybody can snoop the traffic, you are open to a MITM attack.
because you are open to MITM attack, there is no guarantee you client will see a legitimate page.
because the pages are not legitimate and your page is in effect not being served (the guy in the middle is serving the pages), all tricks used server-side are rendered useless.
What can you do? Theorically?
both client and server need to use encryption to make snooping / MITM less susceptible.
assume you cannot have a handshake,
assume your client already has your key and knows how to speak the same gibberish as your server.
how about some SSL over HTTP but wrapped in base64-encoded message for some gibberish?
But wait... Since you said no magic binary, or plugin, not even RSA, I don't know if any of this is possible save for (some potentially very weak) in-house encryption.
--
You can try to replicate it to some point, by using public key encryption (GPG maybe) and making use of browser caching.
This is not something secure, even just putting up SSL won't be enough for a sophisticated attacker, you need to make use of HSTS, public key pinning etc to just to consider a web site secure today.
The rest of the answer is just food for thought.
Create a public-private key pair. Keep private one secure.
Create a js file containing the public key and a encrypt function, find a secure encryption algorithm. This function should encrypt a given string (serialized form) with an additional timestamp, to avoid a replication attack.
Serve this file with Cache-Control:public, max-age=31536000 HTTP header. We try to mitigate when the attacker tries to replace the script. The file will always be served from the browser cache.
Send all the forms via Javascript, using the encrypt function. Serve these with the same header as above.
At the server side, decrypt the data, check the timestamp, if it's still valid. Do you thing, if not, discard it.
Create a cookie token which can only be used once for a very short amount of time. If the attacker captures a cookie, he won't have much time to do stuff. However, if the attacker is fast enough, then he might log the original user out.
Change the cookies with every response. But then what do you do when the user sends multiple requests at once and then they arrive in the reverse order? Which cookie is valid? This creates tons of problems at the cost of a false sense of security.
Any listeners won't be able to make use of the data going back and forth, and they won't be able to change/inject the existing JS files until the cache expires / user clears the cache. However, any sophisticated attacker can replace the whole HTML file which would discard all the security measurements I have just mentioned. If you can at least serve this file / form over HTTPS, you might get away with it, put them on github pages or whatever. However, if you put the file some other domain, then you need to set up CORS for the receiving domain for this to work.
Another try
One time passwords sent to email.
User fills out their email, clicks a link which then sends a link to their email with a token that will enable them logging in.
User clicks the link
Server checks the token, logs the user in.
Rolls the cookies like the previous example.
All in all, whatever you do, it is not secure. Given a fast, sophisticated attacker, nothing stands in the way.
Get SSL, if the infrastructure does not support it, change it. If your manager does not believe in SSL, convince him/her. Don't create a false sense of security. Protect your user's data, depending on your location, you are legally required to protect the data of your users.
Then let's talk about how to make a site secure with SSL.
Have a look at "The Secure Remote Password Protocol".
Instead of formulating it myself, let me quote from their webite:
The Secure Remote Password protocol performs secure remote authentication of short human-memorizable passwords and resists both passive and active network attacks.
and:
[The] protocol combines techniques of zero-knowledge proofs with asymmetric key exchange protocols and offers significantly improved performance over comparably strong extended methods that resist stolen-verifier attacks such as Augmented EKE or B-SPEKE.
Although the Stanford University doesn't provide implementations for PHP and JavaScript themselves, they link to some 3rd-party implementations.
One of those links leads to "Clipperz", which is an online password manager. It is also available as a community edition on GitHub. There they host their "javascript-crypto-library", which implements the protocol and the "password-manager" itself, which contains backends written in PHP and Python.
I can't say how difficult it would be to extract the relevant portions of code, but maybe you can reuse their implementation (it's licensed under AGPL).
Edit 2014/10/24:
Wikipedia's article on SRP lists some more implementations. Relevant for PHP/JS:
srp-client (JS)
srp-6a-demo (PHP/JS)
The best solution I have seen for somewhat secure HTTP connections is to use a Javascript implementation of md5sum (or some other hash) to avoid transmitting the password in plaintext. You can create a form onsubmit handler in Javascript that replaces the password field with a hash of the original value. This adds a modest amount of security to an unsecure connection, but relies on Javascript running in the browser to work properly.
I guess you care about secure transmission of password to the server? My answer is: dont transmit passwords to the server :)
Infact you may not transmit anything from browser (user) to server to authenticate the user, as an attacker who is spying http traffic would also be able to retransmit the data and authenticate.
Proposal:
Obvious solution would be to use a one-way, one-time transaction authentication originating from server; like a transaction number which can only be used once. Eventually, you still need a secure channel once to sync the list of transaction numbers with user.
You could use something google authenticator, yet you need a secure channel once to setup parameters on either side. If you consider email to be secure, that would be a way to go.
I have the same issue on a system of mine. I have taken steps to try and increase security without compromising the user experience with convoluted mechanisms. What I noticed was that the vast majority of users logged in from the same machine using the same browser, (but not necessarily the same IP address), or from a couple of browsers (eg: desktop or mobile). I decided I could use this to identify a pattern.
1) During registration, users are required to have strong passwords (to prevent dictionary attacks), a security question/answer and standard email verification (as proof of real person)
2) During login, after 5 failed login attempts (not before), a captcha is displayed to prevent brute force attacks.
3) Finally, I created a hash of parts of the user-agent string following a successful login, containing the users OS, browser (general not versions) and language - forming a sort of secondary password. If the useragent hash is significantly different on next login, the user is asked to answer the security question. Then, if this is answered satisfactory, the new UA string is hashed and added to their "safe machines" list, so that they wont be asked again from this machine. This is similar to a mechanism employed by the Steam gaming system.
This has been in use for over a year very successfully with about 700 users and it had the additional benefit of preventing "login sharing" - a problem where multiple users were using the same credentials for convenience!
The answer is shorter, and if you really matter about security you always have options that different levels of bureauocracy.
Absolut security does not exists. The number one flaw is always on the client side, with trojans ans keyloggers. SSL doesn't help with that.
1) Token generators: banks use them, blizzard uses then. It can be a device or an app. Well.. it's expensive.
2) SMS pins. interesting and affordable solution. There is a lot of good prices from trnasactional sms on the market and everyone has a phone capable of receiving it.
3) If you have to use HTTP, you can force a third party oauth service, like google or facebook. That's the best you can do without a token generator.
Use hashing mechanisms to store password and always compare the hashed password then nobody knows the real password even you.
It is very simple but it is effective.However, nothing is completely secure and there are some ways to broke the scurity layers.
Try this : On each request of the login page, send across a nonce and a timestamp.
While posting to server, send the following four details :
The username, the nonce and the timestamp in plaintext.
Then concatenate the above with a separator (Eg: newline) and encrypt using the user's password as encryption in chained-block-cipher mode.
On the server end use the username to lookup the password and verify the encrypted string.
Since the password is never sent across in clear, it is secure and the timestamp can be used to avoid a re-submit of the same data.
To avoid hijacking of session by obtaining the session key through a man-in-the-middle attack, the password or a hash of the password can be stored in-memory by the application on the client end and be used for generating unique session keys for validation by server.
Taking a look at OAuth 1.0 is also not a bad idea.
If you can't use HTTPS or you don't want to use HTTPS, consider using jCryption. jCryption offers encryption for the data being sent through HTTP requests (POST, GET etc.).
You can test the technique here: http://www.jcryption.org/#examples
If you're using Firebug, you'll see that all the data is encrypted.
It has jQuery library to encrypt the data on the front-end and a PHP library to decrypt the data in the back-end.
It is hard to secure the communication without a trusted third party, however, there are some security tricks for you:
DO NOT expose users' sensitive information to public network.
Every sensitive information should be well hashed or public-key encrypted. Pay attention: If you choose to encrypt users' sensitive information by a public-key, please make sure that the user can verify the public-key. For example, you could send some kind of public-key fingerprint to user via SMS or even an auto-call.
Generate a SHARED SECRET after log on successfully
After a secure log on transaction, a shared secret should be generate. The generation procedure could refer to SSL Handshake. Pay attention: Once the shared secret is generated, it must on be transported anymore. The only function of it is to encrypt/decrypt the data between Server and Broswer
There SHOULD be a two-step-verification to avoid repeat attack
May these tricks will help you
Related
I'm trying to improve some code that enables logging in to our application using digital certificates, probably certificates stored on PKCS11 tokens.
It's a Java client server application, with the server on JBoss [Wildfly], and a rich Java thick client. We also have a GWT/Javascript based web client, but this doesn't yet support certificate auth.
The current implementation uses 2-way SSL authentication if certificate authentication is configured, i.e. the server will require a client certificate when the connection is opened. This causes some problems, and in trying to find ways to address them I've been searching madly to see if there is a standard, 'Right Way To Do PKI Auth To A JBoss Application'.
However just about everything I have found on the subject seems also to revolve around using two-way SSL, which kind of implies that is the Right Way to Do It.
It seems undesirable to me, in that the network transport is quite a low-level concern, heavily separated from the application logic and stuff like authentication and user management.
In order to prove the client is a valid user of the system (as opposed to merely someone with credentials endorsed by a CA in the server trust store), the server application logic has to rummage around looking to find the certificate that was used on the incoming connection in order to scrape the Common Name off it. I've discovered that javax.servlet.request.X509Certificate is a standard-ish parameter one can query on the servlet, so it ought at least to be possible.
The other architectural problem this causes is that our app requires reauthentication for the lifetime of certain sensitive operations. If one is using the SSL connection to prove the user has the private key, then logically that would require opening a whole separate connection.
Logically, authenticating with a certificate would seem to require
The server generating a nonce
The client encrypting the nonce using the client's private key
The client sending that encrypted value to the server with the accompanying public certificate [or certificate chain].
Now, that is exactly what happens during an SSL handshake, but obviously a whole load of other baggage comes with it that is irrelevant to the application-level concern of authenticating the user.
I thought about implementing the steps directly myself, but this would seem to violate the first rule of crypto (Don't implement your own crypto).
If the server generates random nonces then that introduces a level of chattiness and statefulness to the process, which is doable but a pain when you are striving for a stateless and clusterable server.
Time-based One-Time Password implementations circumvent this, and seem to be a standardized mechanism for 2-factor authentication that is getting support from Google+ and the like.
However I can't find anything in the way of out-of-the-box libraries that will let me build an implementation using certificates directly from an imposed PKI.
I have a REST API which clients connect over SSL (self signed cert 2048bit)
I was thinking of implementing the following security
The client requests a RSA public key from the server
Encrypts the username / password
Adds these to the header of EVERY REST call allowing the server to be stateless
The application involves users adding credit cards (the numbers themselves are encrypted) and purchasing products so security is critical
We also have very limited time from a iphone client point of view so I was hoping if the above would be suitable?
Usually, when it comes to security, one doesn't want to reinvent the wheel. It's way better to use state-of-the-art technologies, so you'll benefits from others' (likely more skilled than you) work.
If you have a RESTful API on SSL, I don't think you have written your own custom TCP protocol. Likely you'll use HTTP, so since it's on SSL, you are on HTTPS.
When using HTTPS, your browser makes sure that the request is signed and encrypted so that only the other end (the service) can authenticate the client and decrypt the message. So there is no need to encrypt data and using custom headers. A simple cookie-based session is enough so you don't send users' passwords in every request.
I am making a small social network website using Java/JSP. I want to have passwords encrypted and then stored in database. I want to know is it nowadays needed to encrypt passwords client side using javascript (sha1,md5,..) and then send it to server or it is safe enough to ignore client side and just encrypt passwords at server side.
You need to transmit the passwords between the client and server via TLS (SSL). Then, use bcrypt with a cost factor of 16 or more (or PBKDF2 with 64k iterations or more) to hash the password at the server.
If you do not use SSL then there will be security holes with doing client side encryption or hashing in Javascript since a man in the middle attacker could just remove the client side hashing code before passing the page on to the user.
If you do use SSL then there is little to be gained by implementing additional client side security. The only scenario where it would be a benefit is where an attacker can compromise the encryption but not the integrity of the stream (so they can only sniff the data). This seems unlikely, but it is possible.
The additional security to prevent this would require that you first hash the password to match how the server has it hashed (so including the salt), and then hash that with a server provided randomly generated token (that the server also remembers in the session). This ensures that the password cannot be obtained by someone sniffing the connection (provided that the integrity of the stream is not compromised) as well as ensuring that the hashed version cannot be used in a replay attack (random server token prevents its reuse). If you only hash the password by itself client side then there is nothing to prevent an attacker from just using that hashed value to login themselves. Remember, this is in addition to SSL, not in place of it.
Regardless of how the password is transmitted, you should only store a salted hashed version of the password in your database. Ideally using a per user salt (that you store as well), and a secure hash function (SHA-2 for instance instead of SHA-1 or MD5).
The best way to do it is use:
SSL
Client and Server side encryption.
Option 1 is usually enough, however it can still be sniffed and thus it can be useful to send a hashed/encrypted version. This sent version shouldn't be what you store in the database though, it should have some kind of other entropy.
I'm in the "pre-design" phase (if there is such a thing!) for a Java EE app that will use a Swing box on the client end and implement components for both web and server tiers.
I'm instantly presented with some technology choices and have been reading up on the differences between how Kerberos and SSL work. One area that I have not been able to find any answers to has been the subject of how to choose between Kerberos or SSL. In other words, how do you tell when it is appropriate to use either protocol?
Let's assume that the Swing client isn't bound by a particular transport (UDP, TCP or otherwise) and could use either/any. How does one choose between which of these two is a better match for their application?
Thanks!
and suddenly (several months later) a wild Sys Admin appears...
I'm going to have to be a voice of dissent on this. The notion that you would ever establish a PKI without a CA is incredibly absurd. You have to maintain the integrity and performance of the PKI by streamlining the creation process. You have to create and store the certs somewhere, where is that going to be? Boom, you have a CA. Any decent PKI is also going to require a CRL be maintained, is the administrator supposed to just write that by hand? You can also forget about having different types of 509's as the overhead of maintaining that by hand would blow-your-mind-wide-open-and-turn-it-into-grey-slurry.
I suppose you could just manually create the tickets with openssl's CLI and just ftp them to the remote clients, but that gets to be a HUGE hassle for deployments of appreciable size. Essentially, if your deployment is so small that generating the certs by hand (repetitive entering of information and all) and then just not worrying about a CRL is a reasonable plan, you don't need an advanced authentication system at all. Something along the lines of TLS+LDAP (one server cert for confidentiality and not authentication) is more appropriate.
Ok, now that I've cleared some misconceptions, let's actually answer your question: When would you want to use SSL over Kerberos for authentication? x509-based authentication is an incredibly nebulous beast, mostly on account that most people (like Michael-O above) don't realize that SSL work specifically because it's authenticating users. There are a few FTP programs that I know of that authenticate that way, middleware employs it...sometimes (which sounds close to your use case from the java talk), and vpn clients/gateways often authenticate with SSL certs.
Usage of SSL would imply the PKI I spoke of up there, which would work great if your use case involves confidentiality. DoD is a good example of an enterprise that makes extensive use of PKI for functions outside of authentication. In that context, supposing all relevant client programs support x509 authentication makes a lot of sense. It's still an exotic set up, and you would still have to figure out how the end-users will "present" their SSL credentials to the system (client configuration, smart cards, etc) but it would fit together nicely. Besides the odd fit, kerberos authenticates by way of a temporary ticket, whereas SSL certs typically last a long time (which is why a CRL is required) meaning that if the never-changing key is factored on one cert the attacker will have several months of free rides before they have to find a new cert, versus kerberos where they only have it for a day and that's only if the ticket isn't destroyed.
All other cases should use Kerberos authentication when possible. It provides the right layer of security and is actually designed as a large network authentication system, which is why you have things that are hard to duplicate with SSL (like authenticating as a service instead of a regular user) and just plain work for their intended purpose. Your use cases are always going to need to take into account existing infrastructure which is probably going to be kerberos-oriented, sometimes LDAPS-oriented, but almost never x509 authentication-oriented. In other words: whatever you're writing is MUCH more likely to be running in a kerberos infrastructure already, so you might as well plug into that somehow. You'll also benefit more from administrator familiarity with Kerberos-as-authentication than 509-as-authentication. The con on this is that confidentiality outside of the ticket is kind of a joke. NFSv4 has some weak DES (and no I didn't mean 3DES even) encryption that it (somehow) relates to the kerberos ticket but it does authentication and that's basically all it does.
I'd like to see some of x509's flexibility combined with kerberos-style infrastructure (recognition of services and the "one time pad" aspect of having a soon-to-expire ticket) incorporated into a solution that was more widely implemented than x509 is now, but at this stage it's mostly day-dreaming.
Summary:
x509 is good if infrastructure requirements won't be a problem and you'll be using PKI for other stuff anyways, but might be duplicating effort needlessly otherwise or if the deployment is probably going to have a kerberos infrastructure anyways.
Kerberos is a similar but better authentication scheme that is more widely used/understood but won't help you with PKI at all, you get authentication, and that is it.
Comparing Kerberos and SSL/TLS doesn't make sense.
Kerberos is an authentication protocol.
TLS is a protocol for securing the communication between two parties, which relies on mechanisms for authentication and encryption. How they work depend on the chosen cipher suite. Although most usages of TLS (e.g. HTTPS) use X.509 certificates, in which case you're likely to use a PKI for the authentication of the remote party, Kerberos cipher suites can also be used. Few TLS stacks support these Kerberos cipher suites as far as I'm aware (Java does).
It doesn't have to be one or the other. For example, even if you're using SPNEGO (Kerberos) HTTP authentication, it often makes sense to secure the transport using TLS (often with an X.509 certificate on the server side, verified via a PKI). If not, the SPNEGO tokens exchanged in the HTTP headers guarantee the authentication, but the rest of the HTTP messages could have been modified by an attacker.
This could be useful:
http://www.faqs.org/faqs/kerberos-faq/general/section-31.html
Consider that any solution involving Kerberos will be more complicated than SSL because it requires an additional, third component, the Authentication Server, which must be managed and administered (e.g. MS Active Directory) whereas SSL is simply a client/server protocol.
You are mixing stuff. Kerberos is an authentication protocol, SSL ist encryption. Kerberos is the way to go if you are in a corporate environment.
Edit: Kerberos can also encrypt your data traffic transparently. No need for SSL certiticates.
I've inherited a mobile app which sends auth credentials (userid/password) in the clear.
I'd imagine that I have 2 choices:
a) use TLS.
b) write my own auth protocol.
If I choose (b) what are the key guidelines that I must follow to make it it secure.
e.g. how to avoid replay attacks, encryption strategies.
If you use b), the key guidelines are: Don't. If you want it secure, that is.
Try to stick with a).
Writing your own security protocol is not necessary, and a bad idea. It will almost definitely have exploitable flaws. If all you need is to protect the confidentiality of the login credentials, then SSL/TLS is what you should use. It also allows you to more easily upgrade to client certificate-based authentication in the future.
For (b) I guess you do a challenge-response thingy.
Server generates a random string, sends it to the client. Client appends it to the password and hashes the whole thing, sends the hash back to the server. Server does the same calculation, compares the result with what it got from the client. If they match then the client sent the correct password.
The most obvious vulnerability is that if someone snoops both sides of the exchange, they can then run an offline dictionary attack against the password.
For both "you can't get sued for it" and "reasonably protected" definitions of 'safe', for a mobile application, you can assume that the line is secure vs man-in-the-middle attacks and wide open to eavesdropping. SSL/TLS sounds the easiest way to go, but this might depend on your carrier and target phones.
If you can't make TLS work and you need to roll your own, use Diffie-Hellman key exchange and established crypto library (Legion of the Bouncy Castle have a jightweight implementation that is J2ME compliant.)