HMAC/SHA-384 is "stronger" than HMAC/SHA-256 only in a theoretical, unrealistic sense (it can be stronger only if you can envision that HMAC/SHA-256 can be attacked, which is not sensible right now)
On the other hand, if you want to implement SHA-384 on, say, a Javascript platform, you will suffer greatly (both in performance and in mental health)
For your HMAC, you must take care of what to include in the HMAC input
If you compute HMAC over the plaintext (before encryption), then that's fine (on a theoretical basis, this needs HMAC to be a little more than a MAC, it must also avoid leaking information about the input data, but with HMAC this property is achieved)
If you compute HMAC over the ciphertext (after encryption), you MUST include not only the ciphertext but also the IV and the algorithm specification (the "aes128" string)
otherwise, someone could change the IV or switch to a different algorithm, leading to a distinct plaintext, without HMAC noticing anything.
So applying the MAC on the ciphertext, while being "better" in a "provable cryptography" way, is a bit trickier since you must define an encoding which aggregates the plaintext, IV and algorithm specification in a deterministic sequence of bytes.
For details on that MAC+encrypt question, see:
22

Most of the time, when some data must be encrypted, it must also be protected with a MAC, because encryption protects only against passive attackers. There are some nifty encryption modes which include a MAC (EAX, GCM...) but let's assume that we are doing old-style crypto, so we have a standalon...
Oh yeah, another important point: you have some padding, and CBC
if, upon decryption, you find a wrong padding, and report it as such, then you have a weakness (that's the "padding oracle attack").
If you apply the MAC on the ciphertext, no problem: you decrypt only if the MAC said "that's good", and you can report a bad padding in any way you wish
On the other hand, if you apply the MAC on the plaintext, then you must decrypt first, before verifying the MAC.
In that case, it is crucial that you always compute the MAC, even if the padding was all wrong, and that you report "bad padding" and "bad MAC" in exactly the same way (it must not be possible, from the outside, to distinguish between the two occurrences -- hence the requirement for always computing the MAC, so that the timing is constant).
Summary: encryption+MAC, that's tricky. Maybe you should use a combined mode which already handles the subtleties.
EAX mode is a mode of operation for cryptographic block ciphers. It is an Authenticated Encryption with Associated Data (AEAD) algorithm designed to simultaneously provide both authentication and privacy of the message (authenticated encryption) with a two-pass scheme, one pass for achieving privacy and one for authenticity for each block.
EAX mode was submitted on October 3, 2003 to the attention of NIST in order to replace CCM as standard AEAD mode of operation, since CCM mode lacks some desirable attributes of EAX and is more complex.
Encryption and authentication
EAX is a flexible no...
It is an encryption mode over a block cipher (AES), which combines encryption and MAC using a single 128-bit key in a safe way.
It is also lighter on IV requirement: you just need a non-repeating IV; it needs not be uniformly random and unpredictable, as CBC needs (but a random IV from Python's "os.urandom" will be fine for both EAX and CBC)