Architecture : Gui en PHP5 et infra en J2EE ?

Bonjour,

Tu risques des problèmes de compatibilité ou de portabilité si un imbécile
décide, par exemple, de chiffrer les mots de passe dans la base de données
(c'est de la sécurité par le petit bout de la lorgnette, donc très à la
mode).
Je ne comprends pas ce commentaire.

1) la partie technique concernant le chiffrage : dès lors que tu as
accès par deux plateformes différentes à une même donnée chiffrée
stockée en sgbdr, tu peux avoir des incompatibilités de calcul selon
l'algo de crypto choisi (en théorie non, en pratique oui, déjà vécu).
Donc pour éviter ça, on se dit" utilisons une fonction du sgbdr". Ce qui
ne résoud pas nécessairement tous les problèmes car le jour où, comme
récemment mysql, le sgbdr décide de passer d'un algo à un autre (MD5 vs
SHA-1 si ma mémoire est bonne) c'est la chianlit à gérer (cf les
paramètres à la con genre "oldpassword" dans phpmyadmin de mémoire).

2) pour l'inutilité de chiffrer les mots de passe d'accès à
l'application : quand l'attaquant a réussit à extraire du système la
ressource qui contient le login+pass, il est clairement *trop tard* pour
faire de la sécurité, le système est foutu (outre le fait qu'il y aura
bien au moins un luser qui aura un mot de passe crackable par simple
attaque de hash tables), car l'attaquant sera capable d'extraire toutes
les informations confidentielles protégées de toutes façons (et
probablement, s'il sait extraire, modifier, même si c'est moins sûr).
Ajoute à ça que bon nombre d'attaques ne nécessitent pas de la part de
l'attaquant la connaissance du mot de passe d'origine (détournement de
lien type "j'ai perdu mon password", insertion pure et simple d'un
nouvel utilisateur...)

3) si un jour tu migres d'un SGBDR à un autre, tu peux aussi avoir des
surprises.

Donc comme d'habitude, à chaque application ses besoins, et surtout ici,
en termes de portabilité du code (question d'origine) ou de possibilité
de migration ultérieure (toutes les applications gros systèmes sont
concernées, et le problème se pose aussi pour tous les éditeurs/ISVs)
mais de manière générale, ma position est que chiffrer les mots de passe
dans une table de sgbdr n'apporte que des emmerdements et aucune
sécurité supplémentaire tangible. Mais bon, vu le nombre de lignes de
code de différence, perso, je rends toujours ce comportement
paramétrable si le client demande de la crypto.

a++;
JG

Donc pour éviter ça, on se dit" utilisons une fonction du sgbdr". Ce qui
ne résoud pas nécessairement tous les problèmes car le jour où, comme
récemment mysql, le sgbdr décide de passer d'un algo à un autre (MD5 vs
SHA-1 si ma mémoire est bonne) c'est la chianlit à gérer (cf les
paramètres à la con genre "oldpassword" dans phpmyadmin de mémoire).

Il a toujours été clairement indiqué que la fonction PASSWORD de MySQL
ne devait pas être utilisée dans les applications.

2) pour l'inutilité de chiffrer les mots de passe d'accès à
l'application : quand l'attaquant a réussit à extraire du système la
ressource qui contient le login+pass, il est clairement *trop tard* pour
faire de la sécurité,

C'est une condition nécessaire mais pas suffisante.

le système est foutu (outre le fait qu'il y aura
bien au moins un luser qui aura un mot de passe crackable par simple
attaque de hash tables), car l'attaquant sera capable d'extraire toutes
les informations confidentielles protégées de toutes façons (et
probablement, s'il sait extraire, modifier, même si c'est moins sûr).

Mais le temps de casser le mot de passe, on aura pu se rendre compte que
le système a failli et remédier au problème, il faut quand même un peu
de temps pour casser un mot de passe de 8 caractères en md5 par force brute.

3) si un jour tu migres d'un SGBDR à un autre, tu peux aussi avoir des
surprises.

Un principe simple est qu'il ne faut jamais basé une impléméntation sur
un SGBDR spécifique, la fonction de hachage doit être dans le programme,
la plupart des langages disposentde ces fonctions de hachage ( md5, sha1
... )

Il est clair qu'il ne faut pas croire que parce qu'on a protégé les mots
de passe par une fonction de hachage on est à l'abri. On peut mettre en
place toutes les fonctions de sécurité qu'on désire, l'application
pourra toujours être attaquée. Je crois qu'en matière de sécurité c'est
avant tout le temps dont on dispose entre l'attaque et la résolution du
problème qui est déterminant, plus l'attaquant mettra du temps à entrer,
plus l'application sera protégée.

John Gallet a dit le 24/05/2005 à 09:30:

Pour les arguments 1 et 3, il suffit de choisir un algorithme de
chiffrage et de s'y tenir.
Tu choisis MD5, et bien, quelle que soit la machine, quel que soit le
SGBD, il n'y aura aucune incompatibilité : MD5 est toujours MD5.
Les trucs de type PASSWORD() sont à éviter, il faut utiliser directement
l'algorithme (par exemple MD5()).

aucune
sécurité supplémentaire tangible

Ben si, s'il arrive à bypasser à un certain niveau le système de
sécurité, quoi qu'il fasse, il n'aura pas le mot de passe réel dont il
pourrait avoir besoin pour passer un autre niveau du système.
De plus la plupart des gens utilisent le même mot de passe partout. Si
un pirate arrive à pirater un site de confiance d'un utilisateur et à
récupérer son mot de passe, il peut usurper son identité sur tout un tas
d'autres sites.

John GALLET wrote:

Sécurité de quoi ? Il n'y a pas moins ni plus de failles sur une
architecture tomcat+jsp qu'apache+php.
La faille vient en général du développeur :)

Montée en charge : non, justement. Il n'y a qu'à regarder le superbe
site des impôts, en java machin-chose
Faudrait savoir ce qu'ils avaient prévu côté serveur, et si ça a pas été

codé avec les pieds.

Mais je m'interroge sur les inconvénients potentiels :
- est-ce une architecture exotique ?
Inhabituelle oui.

Faudrait déjà savoir si techniquement c'est faisable.

A mon avis non, donc c'est inutile d'aller plus loin.
La seule technologie qui pourrait faire passerelle entre des composants J2EE
et un script PHP c'est xml.
Et dans ce cas, avec 4000 utilisateurs en simultané, on va bien rire....

La première question qui me vient à l'esprit, c'est : quel est l'intérêt de
faire cela ????
Tout ce que tu peux faire en PHP, tu peux le faire tout aussi facilement
avec des JSP. (et inversement).

La question ne serait-elle pas plutot client léger VS client lourd ?
J'ai l'impression en lisant ton message que tu mélanges un peu tout.
Déjà en client léger, le GUI ne sera ni en JSP ni en PHP mais plutot en
HTML/javascript.
(on va mettre de côté l'xml)

- vais-je de toute façon devoir utiliser des applets Java pour les
fonctions client un peu trop complexes pour PHP qui est exécuté sur
le serveur (si je ne m'abuse) ?
Que ce soit en JSP ou en PHP, tu seras limité par les possibilités de

l'html.

- l'absence d'intelligence sur le client va t'elle me pénaliser ?
Je confirme, un client con c'est pénalisant.

Mais le plus pénalisant c'est l'absence d'intelligence coté architecture ;)

- est-ce que je vais plus perdre à mélanger deux langages qu'y
gagner ?
Tu ne peux qu'y perdre, cela ne fait aucun doute.

bref, est-ce farfelu de faire du J2EE pour les composants de base,
et PHP pour le front end ?
Oui.Sans utiliser d'xml pour communiquer entre les 2, je ne vois pas trop

comment cela peut etre possible.

Tu risques des problèmes de compatibilité ou de portabilité si un
mais non, java c'est portable, c'est bien connu :)

imbécile décide, par exemple, de chiffrer les mots de passe dans la
base de données
J'ai eu envie de faire ça une fois pour le fun (faut tjs avoir une part

d'imbécilité en soi, pour éviter de faire des erreur en prod) mais j'ai tjs
pas bien compris l'intérêt hormis pour la beauté du geste, faire briller les
yeux du client, et lui facturer qq jours de plus...
Dans le cas précis, pas de souci, c'est en java qu'il cryptera/décryptera
les mots de passe.

En revanche, il faut clairement avoir été bercé trop près du mur
pour, sur une machine de production d'une application un peu
critique, instancier des classes java en php et réciproquement.
ça m'intéresserait de savoir comment tu instancies une classe java en PHP et

réciproquement....


--
Lionel, qui n'a tjs pas compris ce que php venait faire dans cette
histoire...

John Gallet wrote:

2) pour l'inutilité de chiffrer les mots de passe d'accès à
l'application

L'important c'est surtout de le chiffrer sur le postit (retourner le clavier
d'un utilisateur pour trouver le postit) ;)
Plutot que de sécuriser un mot de passe dans la base, il vaut mieux
commencer par sécuriser la base, non ?

Lionel a dit le 24/05/2005 à 17:05:

Oui.Sans utiliser d'xml pour communiquer entre les 2, je ne vois pas trop
comment cela peut etre possible.

Il existe un nombre infini de manières pour communiquer entre les deux.
En ligne de commande avec stdin/stdout par exemple.
Mais pourquoi pas n'importe quelle technique d'IPC si on a un démon Java
qui tourne en fond.

ça m'intéresserait de savoir comment tu instancies une classe java en PHP et
réciproquement....

Avec les modules expérimentaux correspondants.

2) pour l'inutilité de chiffrer les mots de passe d'accès à
l'application : quand l'attaquant a réussit à extraire du système la
ressource qui contient le login+pass, il est clairement *trop tard* pour
faire de la sécurité, le système est foutu (outre le fait qu'il y aura
bien au moins un luser qui aura un mot de passe crackable par simple
attaque de hash tables), car l'attaquant sera capable d'extraire toutes
les informations confidentielles protégées de toutes façons (et
probablement, s'il sait extraire, modifier, même si c'est moins sûr).

L'intérêt de ne pas mettre le mot de passe en clair vient du fait que les
utilisateurs ont tendance à utiliser le même partout.
Donc, si on récupère un mot de passe en clair pour un utilisateur donné,
sur une application X, on va avoir tendance à vérifier le couple sur
d'autres applications, en commencant éventuellement par les classiques
(ebay, hotmail, etc...).

C'est pour les mêmes raisons, par exemple:
1) que si on fait de l'authentification dans Apache, on peut après
récupérer le login qui s'est authentifié, mais pas le mot de passe
2) que, par exemple, dans les logs de démons (style sshd), on n'écrit
jamais les mots de passe qui ont été recus.

mais de manière générale, ma position est que chiffrer les mots de passe
dans une table de sgbdr n'apporte que des emmerdements et aucune
sécurité supplémentaire tangible.

Si cela n'apporte pas de sécurité supplémentaire à l'application (modulo
le fait que si on sait que le mot de passe est stocké en clair dans le
SGBDR, un attaquant va peut-être s'orienter plus vers une attaque visant
à récupérer ce mot de passe, comme une injection SQL, que vers une
attaque visant à contourner/détourner le système d'authentification de
l'application dans son ensemble), cela apporte une sécurité
supplémentaire à l'utilisateur pour la raison évoquée plus haut.

Question emmerdemment, si on fait le cryptage dans le SGBDR, suffit
d'utiliser la fonction idoine qui ne change pas (ex: digest() dans
postgresql qui prend comme paramètre le nom de l'algorithme à utiliser),
et on peut le faire aussi dans l'application.

Très souvent, quand les gens se disent que cela ne sert à rien de crypter
l'information dans la base de données, car celle-ci est ``inviolable'',
au final on en arrive à trouver plein d'informations en clair (style
numéro de carte bancaire au hasard)... informations qu'on retrouvera
ultérieurement sur les bons channels IRC.

--
Patrick Mevzek . . . . . . Dot and Co (Paris, France)
<http://www.dotandco.net/> <http://www.dotandco.com/>
Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>

Tu choisis MD5, et bien, quelle que soit la machine, quel que soit le
SGBD, il n'y aura aucune incompatibilité : MD5 est toujours MD5.

Non. Ca c'est la belle théorie. J'ai déjà eut des problèmes en particulier
pour comparer des md5 générés sur microprocesseur alpha. Et je ne compte
pas les bugs temporaires. Ca me fatigue. Si je dis qu'il y a des problèmes
ce n'est pas pour faire le malin, c'est parce que j'ai déjà perdu des
heures dessus.

Ben si,
Non.

Je me répète : dès lors qu'un attaquant possède la liste des couples
login/pass, toute chiffrée qu'elle soit, il en a pour quelques minutes à
quelques heures à trouver au moins un accès valide, même par une bête
attaque de type hash table/rainbow table.

Donc si vous préférez : chiffrer les mots de passe en base permet de
gagner 2 heures. Allez, osons : 3h s'il va au macdo le temps que le script
tourne. Et comme l'attaquant possède tout son temps, en moins de 48h il
aura 30 à 50% des mots de passe par force brute. Pourquoi croyez vous
qu'on a séparé /etc/passwd et /etc/shadow ?

Si vraiment vous voulez chiffrer vos mots de passe en sgbdr alors ça n'a
de sens que si vous avez un module automatique qui en gros :

- force la présence de signes de ponctuation et/ou utilise une librairie
comme http://fr3.php.net/manual/en/ref.crack.php pour vérifier que le mot
de passe choisi n'est pas complètement simpliste avant de l'accepter

- force l'utilisateur à le changer tous les mois, en conservant plusieurs
occurences antérieures

- vérifie que l'utilisateur n'incrémente pas bêtement (coincoin1,
coincoin2...)

- désactive le droit de login à l'application au bout d'un certain temps
de non connexion (2*l'intervalle de changement de mot de passe par
exemple).

-(et je suis tout à fait d'accord sur la chasse aux post-its...)

Sinon, si c'est de la fausse sécurité, et cela leurre tout le monde en se
disant "oh, c'est pas grave si on accède à la donnée, elle est chiffrée"
(déjà entendu en open space de développement trop souvent comme connerie),
ce qui est la politique de l'autruche.

Très honnêtement, le seul et unique intérêt que je vois à chiffrer le mot
de passe est d'éviter la tentation de l'envoyer en clair par mail quand
toto l'a (encore) oublié. Au moins si on force à en choisir un nouveau et
qu'un attaquant détourne l'action, quand toto se logguera, il y a une
(petite) chance qu'il se demande pourquoi son mot de passe a été changé.

Enfin moi ce que j'en dis hein...

JG

John GALLET wrote:

Sinon, si c'est de la fausse sécurité,

Le problème de la vraie sécurité, c'est pour la mettre en pratique.
Car pour que tes règles soient efficaces, il faut en plus que tous
les mots de passes soient différents. Je ne doute pas que ça tombe
sous le sens pour toi.

Pour mon travail, je dois utiliser une cinquantaine de couples
login/mots de passe. Chez moi, j'en utilise une dizaine d'autres.

Je suis totalement incapable de mémoriser une soixantaine de vrais
mots de passe qui soient tous différents et qui changent de manière
fondamentale tous les mois.

Stéphane
--
Pour me répondre, traduire gratuit en anglais et enlever le .invalid

L'invective peut se faire dans le velours. Elle est d'autant moins
plaisante
qu'elle ne s'accompagne même pas d'une tentative de réponse. Ce qui fait
que
nul ne sait si vous même avez la compétence pour juger de la mienne...

Si vous essayez de réaliser:
1- une couche d'ejb métier [donc personnel de dev (très) compétent en java]
2- une couche d'affichage servlet/jsp [car la container de servlet est
intégrée au serveur d'application au niveau permission, transaction et
annuaire ...)]
Posez-vous le problème dans l'autre sens ... "Pourquoi aurais-je besoin de
php ???" (et d'une équipe à double compétence)

Si on entre un peu dans le détail,
Première approche:
Vous accédez aux ejb via leurs homes récupérés depuis JNDI.
Vous allez dans ce cas utiliser l'extension "Java Integration", et du coup
passer votre temps à caster des types java <-> php, pour trouver la bonne
méthode à invoquer sur l'interface remote du bean (pas très productif). De
plus, il est souvent pratique de stocker des informations dans la session
HTTP de l'utilisateur. Les proxys d'ejb sont sérialisables ce qui en java
offre la possibilité de les stocker dans les sessions tomcat/jetty ou autre,
depuis php l'affaire est impossible ...

Seconde approche:
Vous accédez aux ejb directement avec une implementation de rmi-iiop pour
php (au moins un projet existe mais j'ai zappé l'adresse). Je n'ai pas de
remarque sur ce point, sauf que c'est clairement réinventer la roue, car ces
fonctionnalités sont déjà implémentées dans les proxy java produits par les
serveurs d'application.

Enfin, il existe surement d'autres moyens de "brancher php et java/ejb"
(notamment faire tourner php dans une servlet), mais dans quel but, sachant
que tout est déjà mis à disposition et de façon plus pratique dans les
serveurs d'application. (cf jboss):

Pour conclure, par rapport à la production (X)HTML ou autre, que vous
utilisiez Php ou Java c'est pareil. Des moteurs de template existent dans
les deux environnements, idem pour des implémentations du modèle MVC (ou
d'autre pattern component-based and event-driven ...). Ensuite suivant le
contexte et les compétences de l'équipe de dev ont tranche ET DANS CE CAS
TOUT IMPOSE pour ui, JAVA (avec Struts ou d'autres).

...et qu'est ce que vous fais penser que je suis un décisionnaire pour
motiver votre intervention ?
Votre première question et cette réponse ...

(Pour finir, ca fait longtemps que les choix technologique stratégiques
des
grands projets ne sont plus laissés aux techniciens :-)
Et quand les projets plantent, c'est la faute des téchos .. on connait la

musique

--
Cléo