Essentially, a hardened child key is is computed with hash(parent private key + index)
, whereas a non-hardened child key is computed with hash(parent public key + index)
.
So what practical consequences does this have?
With an extended public key, you can derive non-hardened child public keys. This is useful in situations where you want to accept payments without immediately being able to spend them. For example, if you had a website selling alpaca socks, your server could use an extended public key to accept payments without losing all of your money if it got hacked. So that's a reason why you might use non-hardened derivation.
With an extended private key, you can also derive hardened keys.
However, non-hardened public keys are weaker when an attacker has 1) the extended public key and 2) one of the non-hardened private keys that was derived from it. In that circumstance, the attacker can work out the private key of the extended public key, and therefore get every key that can be derived from that, hardened and non-hardened.
So what should your app use by default?
You should use non-hardened keys, and disable the ability to export private keys when that would allow an attacker to compromise other keys in the wallet. Even if an attacker gets ahold of one of the private keys, in situations where the attacker doesn't have access to the extended public key, non-hardened is equivalent to hardened security. In my mind, the features of non-hardened keys outweigh the added security of hardened keys.
However, if you don't need the features of non-hardened keys, then you should use hardened keys, because they're more secure.