Bonjour,
Je souhaiterais développer une appli de gestion de budget/finance personnel, un peu comme Microsoft Money en simplifié.
Ce serait une appli Web pour pouvoir l'utiliser de partout. Par exemple en vacances ou au boulot.
Le PHP étant le plus simple pour l'hébergement.
Je souhaiterais rendre un peu confidentiel les informations stockées en bases.
Surtout les montants et les libellés des opérations , pour éviter qu'un admin chez l'hébergeur s'amuse via un simple "select" SQL, à récupérer tout l'historique des opérations bancaires de l'utilisateur.
En terme d'utilisateurs ce sera uniquement moi et éventuellement des personnes de mon entourage proche qui en aurait le besoin.
Je ne recherche pas une sécurité forte, donc pas de SSL. Je pense juste stocker certaines infos cryptées en bases
Je part sur une base MYSQL et je pense utiliser les fonctions AES_ENCRYPT et AES_DECRYPT pour les colonnes confidentielles.
La clef sera le mot de passe de l'utilisateur qui lui même sera stocké basiquement en MD5.
 
Cela vous semble t-il une bonne stratégie?
Les performances des requêtes SQL seront-elles très dégradés par l'usage des fonctions de cryptage AES ?  
Les colonnes cryptés ne seront ni indexées ni utilisées pour des jointure.
Je ne pense pas qu'un utilisateur dépassera les 5000 enregistrements pour la table.

Oui, AES_ENCRYPT est très bien.
 
Comme indiqué, dans la doc, il faut avoir des champs de type BLOB au lieu de NUMBER ou VARCHAR.
 
Au niveau de la vitesse, je pense que ca devrait aller sans problème. D'une part, d'un point de vue théorique, le cryptage est une opération qui utilise principalement la CPU et la RAM, or c'est beaucoup plus rapide que les accès disque ou les accès réseaux qui sont les principales causes de ralentissement pour les applications de gestion. D'autre part, d'un point de vue pratique, j'ai fait ce genre de chose, et la baisse de vitesse n'a pas été sensible bien que le volume des données fut assez important.

Merci pour ta réponse olivthill. Cela va dans le sens des résultats de mes recherche sur internet.
Maintenant je me penche sur un autre problème.
Ne pouvant utiliser de SSL, existe il un moyen simple d'éviter la soumission du mot de passe en clair de l'utilisateur entre le navigateur et le serveur ?

Le mot de passe s'affiche dans la l'URL s'il est envoyé dans une form utilisant la méthode GET.
 
Mais ce mot de passe est invisible s'il est envoyé dans une form utilisant la méthode POST.
Il n'est visible qu'avec des outils que n'ont pas les utilisateurs ordinaires.

Je le sais.
Je ne cherche pas à mettre en place une grosse sécurité car au final les informations sont juste personnelles mais pas critiques.
A défaut de pouvoir utiliser du SSL, je souhaiterais protéger le mot de passe pour éviter notamment lors de l'usage de l'appli hors de chez moi, que le mot de place circule en claire sur le réseau.

On peut le crypter dans un javascript.
On avoir des mots de passe différents en fonction de l'heure ou d'un code dans la page.

Mon idée simple dans un 1er temps est que le serveur va envoyé une clef (random ou timestamp), qui sera utilisé coté client en javascript pour crypter le mot de passe.
Il y a bien sur une faille, mais les 2 avantages sont que le mot de passe ne passe pas en clair et que ce mot de passe crypté est valide uniquement le temps de la session utilisateur.
Voilà sur quoi je pense partir