Re: Re: [Obm] Configuration de la période de jours travaillés dans le module "Gestion des temps"

[dabfus]

Le 8 septembre 2008 23:53, Thomas Cataldo <thomas.cataldo at aliasource.fr> a
écrit :

>
> En fait un fonctionnement réellement correct serait d'appliquer ça :
>
>      The glibc2 version of this function supports additional
> encryption algorithms.
>
>       If salt is a character string starting with the characters
> "$id$" followed by a string terminated by "$":
>
>              $id$salt$encrypted
>
>       then  instead  of using the DES machine, id identifies the
> encryption method used and this then determines how the rest of the
> password
>       string is interpreted.  The following values of id are supported:
>
>              ID  | Method
>              ---------------------------------------------------------
>              1   | MD5
>              2a  | Blowfish (not in mainline glibc; added in some
>                  | Linux distributions)
>              5   | SHA-256 (since glibc 2.7)
>              6   | SHA-512 (since glibc 2.7)
>
>       So $5$salt$encrypted is an SHA-256 encoded password and
> $6$salt$encrypted is an SHA-512 encoded one.
>
>       "salt" stands for the up to 16 characters following "$id$" in
> the salt.  The encrypted part of the password string is the  actual
> com‐
>       puted password.  The size of this string is fixed:
>
>       MD5     | 22 characters
>       SHA-256 | 43 characters
>       SHA-512 | 86 characters
>
>       The characters in "salt" and "encrypted" are drawn from the set
> [a–zA–Z0–9./].  In the SHA implementation the entire key is
> significant
>       (instead of only the first 8 bytes in MD5).
>

Tout à fait ! Cela serait la façon propre de le faire, dans mon cas il
s'agit d'un rapide dirty hack.


>
> Normalement ça serait compatible avec php qui utilise l'appel crypt de
> la libc, mais ma préférence reste l'utilisation du PLAIN en bd et
> d'authentifier sur le ldap.
>

Le PLAIN en bd pose tout de même un sérieux problème de sécurité (tout
stockage de mots de passe en clair à la place de hashs pose un problème de
sécurité, en cas de "simple" compromission de la bd (faille de SQL Injection
par exemple), ce sont des mots de passe d'utilisateur qui sont révélés, et à
coup sûr utilisés dans d'autres applications ...).

C'est pourquoi je préfère la méthode crypt (quand son niveau de sécurité est
suffisant), de même que de basculer en HTTPS l'accès Web et le Tomcat pour
OBM-Sync.


>
> >
> > mais le comble (cf. thread) c'est que j'ai toujours mon décallage de deux
> > heures, même avec le timezone de MySQl correct :)
>
> Etes vous sur que les timezones des clients et du serveur sont bien
> Europe/Paris ? les dates dans les logs de tomcat sont elles ok ? (par
> exemple sur la ligne de log getSync(user, date))


Non c'était bien le problème tel que exposé dans un de vos précédents posts
que je n'avais pas vu initialement, car je n'avais pas configuré
correctement la timezone pour Tomcat, donc tout fonctionne désormais, merci
! (peut-être à ajouter sur www.obm.org dans
http://www.obm.org/doku.php?id=install_obm_sync_server_from_sources ?)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.list.aliasource.fr/pipermail/obm/attachments/20080909/0ebf7670/attachment.html