Programatically thrown Exceptions vs JVM thrown Exceptions

How do you know whether an exception is thrown by the application (programmatically?) or thrown by the JVM?

I understand as their name reveals definition. But my question is-- On which ground you will categorize any exception into these two. Any reasoning or concept?

For example: NullPointerException is JVM thrown whereas NumberFormatException is Programmatically thrown exception. Why?

Nullable boolean

Just thot its out of the box... A boolean with three values... It reminds me of a statement by a teacher ... Both of u three come here...:)
http://codingangry.com/index.php/site/C8/

Https.....

Before understanding Https, first we will have to understand some underlying concepts.

Cryptography

When we want to encrypt some information so that only the actual receiver can read the information, we are using the cryptography.To encrypt some text we need the following things.

• Cypher - A cipher (or cypher) is a pair of algorithms which create the encryption and the reversing decryption


• Key - A phrase which will an input to the Cypher. Algorithms will use this key to encrypt/decrypt the text. If the algorithms will work without the key, then it is useless. Anyone who knows which algorithms are being used to encrypt/decrypt, will be able to encrypt/decrypt the information. So key is important. Depending upon the keys being used for encryption and decryption, we have two variants of cryptography.
  

• Symmetric-Key Cryptography - In this the same key is used for encryption as well as decryption algorithm. Data Encryption Standard(DES) and Advanced Encryption Standard(AES) are tho such algorithms.


• Public-Key Cryptography - Disadvantage with the Symmetric-key cryptography is that the 'key' will be shared between sender and receiver. So the key will have to send from the sender to the receiver. Now someone can steal this key while it is being sent.

  In Public-key cryptography key-pairs are used. Let's say A wants to send some message to B. A will have two keys one private and other public. Similarly B will have pair of keys - private and public. The private keys are 'private' so only A will know his private key and only B will know his private key. Public keys are for public so everybody knows A's and B's public keys.
  

  If A wants to send some message to B, then A will encrypt the message from B's public key. Now this encrypted message can be decrypted only from B's private key. This private key is known to B only, so only B can decrypt this message. Similarly if B wants to send some message to A, B will encrypt the message from A's public key.

  RSA and DSA are two such algorithms.

Digital Signatures

Digital Certificates

SSL/TLS

Http- Secrity- Form Based Authentication

First of all form-based authentication is not an http specification. Http specification only supports Basic and Digest authentication. Form based authentication is servlet specific.

In form based authentication, user is presented one page in which we have the username and password text boxes. User fills in the details and submits the form. This information will travel over the network.

If for some reasons we can not use SSL, then it is not advised to use form-based authentication. As the username and password will travel over the network in plain text and can easily be retrieved. ( Not sure how easily though, I have got no experience with network sniffing. But it will be interesting to check this out though).

One will use the form-based authentication only when he is unhappy with the pop-up that the browser throws if we use Basic or Digest Authentication. But if we can not use SSL then I guess it is better to accept Basic/Digest dialog box than to provide form based authentication. In Basic/Digest authentication the password will not travel as plain text.

If we are using SSL then any authentication can be used. Because the complete channel between the client and server will be encrypted. And nothing will be transmitted as plain text.

Http- Security- Digest Authentication

We have already talked about the basic authentication. And we also saw the issues with Basic Authentication. Digest Authentication is more secure. In this, as the client present the request to server.


GET /dir/index.html HTTP/1.0
Host: localhost


Server responds with the following challenge.


HTTP/1.0 401 Unauthorized
Server: HTTPd/0.9
Date: Sun, 10 Apr 2005 20:26:47 GMT
WWW-Authenticate: Digest realm="testrealm@host.com",
qop="auth,auth-int",
nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
opaque="5ccc069c403ebaf9f0171e9517f40e41"
Content-Type: text/html
Content-Length: 311
(plus html for the 401 Unauthorized text)


"WWW-Authenticate: Digest" tells the browser that it has to use the digest authentication. Browser will first pops-up the window in which the user types the user name and password. Once the browser has this information it performs the following steps.

1. Browser will generate the HashNumber of username:realm:password.
N1 = H(username:realm:password)

2. Browser will then generate one nonce( nonce stands for number user once, this is kind of UUID). It will also generate the request number. Then it will create one more hash
N2 = H(N1:browser nonce:browser request number: server nonce)

3. Browser will send this information back to server in "Authorization" http header in the following format. The actual hash value N2 is the value in response field( see below)


GET /dir/index.html HTTP/1.0
Host: localhost
Authorization: Digest username="Mufasa",
realm="testrealm@host.com",
nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
uri="/dir/index.html",
qop=auth,
nc=00000001,
cnonce="0a4f113b",
response="6629fae49393a05397450978507c4ef1",
opaque="5ccc069c403ebaf9f0171e9517f40e41"


4. On server side the password for various users are not stored in plain text. Server will keep the same hash of username:realm:password(It will be same as N1 in step 1) and thus it will save cpu time. Server will use the username value to retrieve the corresponding hash N1. Now server will use all other information nc(request number), conce(browser nonce), nonce(server nonce) from the reuest to calculate the hash N2. If everything is correct then this generated value should be same as value in reposne field.

5. Now the server will present the requested page to client.


HTTP/1.0 200 OK
Server: HTTPd/0.9
Date: Sun, 10 Apr 2005 20:27:03 GMT
Content-Type: text/html
Content-Length: 7984
(followed by a blank line and HTML text of the restricted page).


MD5 is the hashing algorithm(H in our case) which is widely used for generating the hash value. This algorithm converts any string to 128 bit value. It's not easy to crack it and it is highly unlikely that by looking at the Hash one can tell the original value.

Advantages

The main advantage is that the password can not be retrieved from the data that is travelling over the network.

Replay Attack
In Basic Authentication, if a person retrieves the authorization header string; He can use it to start a new conversation with the server. So he can replay that string till the time user changes his/her password. He can start a new conversation with the server any time he wants.

Digest authentication provides security against these attacks. Since the digest values also includes server nonce, browser nonce( which changes very frequently probably in milli seconds) and request number( which changes for every request); the digest that travels in the response field doesn't remain the same. So the same digest can not be replayed by some bad soul. So he can not start the conversation with the server. Because he can not generate the digest of username:realm:password. And by looking at the digest, he can not guess the username and password.

Man-In-The-Middle Attack
If there is a person who is intercepting each and every request, then even this authentication fails. He will intercept every digest send to the server and can modify the content which is being send over the network. But this will work till when the actual user is talking to the server. It is like person A is calling to person B and person C is also listening ( map be modifying the conversation as well). But person C can not start a new conversation with person B.

So then what is secure
Basic or Digest authentication are just the Authentication mecanism. The information that travels over the network is still plain text. It will not protect the Credit card number and all other sesitive information travelling over the network. For that one will have to use SSL(Secure Sockets Layer)/TLS(Transport Layer Security)...

Http - Security- Basic Authentication

There are two authetication mechanism that are built in Http protocol itself

• Basic Authentication
• Digest Authentication

In this post I will try to explain ‘Basic Authentication’.

In ‘Basic Authentication’ you protect portion of your webserver through basic authentication. For this ,in web.xml you provide a URL pattern for which basic authentication applies. Now when a request comes for that particular URL, the server sends the response back. Server sends a challenge back to the browser in the following form –

Client request (no authentication):

GET /private/index.html HTTP/1.0


Server response:

HTTP/1.0 401
Authorization Required
Server: HTTPd/1.0
Date: Sat, 27 Nov 2004 10:18:15
GMT
WWW-Authenticate: Basic realm="Corp Login"
Content-Type: text/html
Content-Length: 311

plus some more html...


Server tells the browser that the resource being asked is protected.
Seeing this the browser pop us a window asking for username and password.

Now the user provides the username and password in the popup window.
Browser uses base64 encoding to encode the provided user name and password and sends that back to server.


GET /private/index.html HTTP/1.0 Host:localhost
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==


The server will decode the user name and password and will compare this with the stored values. The server will retrieve the username from the decoded string and then it can compare thecorresponding password. If username and password is correct, then the resource will be presented to the client.

This one is simple, but there is one potential security hole. The username and password is travelling over the network. Someone can sniff the network and take out the bytes and since it is a known Base64 encoding. He can decrypt it and then can use the same credentials. Even if the person doesn’t decode the password, just by sniffing the network he can have the string which is being sent in Authorization header. Now he can simply send this header with every request and thus can fool the server in believing that it is the correct user who is sending this information.

For More security we need something else..digest authentication....

There are couple of questions though

• so the browser caches the encoded username:password string? If we access other url which is protected by the same realm we will not be asked for the password..right?
• But if we access the url which is protected by other url, the browser will prompt for the password. So browser cached this string(username:password) for every different realm?
• And these realm will not be shared accress the websites
• So this caching of information happens through cookies?