I'd like some opinions about the flow I'm building for any mobile application that needs to send a combination of user and password. My idea is to encrypt the password using AES-256, generating a random passphrase and IV to generate the key. The idea is that when the password is first generated, it send to the server the encrypted password, and the IV. the IV and encrypted password will be stored at server, in a redis DB and the key, and the encrypted password, will be on the mobile device only (the IV will not be stored on the device). So each time the user needs to login, sends the to the server, the encrypted password and the key, with the IV stored, the server decrypt both encrypted password sent and the one saved in the DB, using the key just sent and the IV already on server.
In case the user wants to change their password, encrypted password, key and IV is generated again and is sent the old one too (key and encrypted password) if they match, the values are updated in server and send a notification to the client to update them too.
All of this transactions will take place inside a SSL tunnelling too.
Do you think this is secure? if not why? any other option to encrypt/decrypt passwords in a secure way from a mobile device to a server?
The best way to do it would be to do a hash of the password on the client side before sending the data and send the hash. Then have the server do it's own hashing on that hash so that the password never has to leave the client and the plain text password can not be derived from bruteforcing the stored hash.
The KDFs (pbkdf2, scrypt, bcrypt) that i listed before are time consuming so you probably don't want to do it on the client and then on the server unless security is more important than normal. A KDF is used to prevent someone from bruteforcing the password from the hash. This means that if your table storing the users hashes are compromised, the plain text of your users password is still safe. If for example, you do the KDF on the client and say a simple salted MD5 of the KDF produced hash on the server, then the users plain text password will be safe but it may be easy for someone who was able to get access to the stored hash (meaning the server is compromised) to log in as that user. If your site/app is stackoverflow it may not matter if a user account gets compromised if the server itself is already compromised. On the other hand if you're paypal, someone who gets access to an account can get access to the users bank account which they would not be able to do simply by gaining access to the hash table. In this case doing a KDF on both client and server would be optimal.
As for using SSL, that's good if you have a method of verifying that the server is actually your server and there is no MITM going on. If either of those are compromised, then sending the password in plain text will allow an attacker to gain access to the plain text password