Re: [Phpgroupware-developers] Re: [ phpgroupware-Bugs-445721 ] email password not saved.

[Miles Lott]

Please do not commit any more changes to the crypto or
sessions classes.  Submit patches to one of the project
admins.  Jengo most certainly needs to be involved in this.

Del wrote:
> 
> Tony (Angles) Puglisi wrote:
> >
> > Del,
> > Again, hack at it and sent me the file(s) (as attachments to an email). My 
> > brain is
> > too simple for these modern things, but I do know that I can commit a file 
> > :)
> 
> OK, will do.  Not tonight, I've been driving for 10+ hours and my brain is 
> fried.
> 
> One question before I start:  Do I have permission to change the underlying 
> encryption
> type for mcrypt 2.4 from 3DES (triple DES) to Rijndael?
> 
> This will break pre-stored encrypted passwords, but provide an order of 
> magnitude
> performance and security benefit.  My understanding is that pre-stored 
> encrypted
> passwords are broken at the moment anyway.
> 
> Any objections from the other developers?
> 
> (trust me, I'm a cryptogeek:  DES should have gone into the dustbin of history
> ages ago, and 3DES with it).
> 
> > ahh.. as far as email goes, we only need to do crypto on a string, and a 
> > short
> > string at that, the pasword. Therefor to program for encrypting objects is 
> > over
> > kill for us but, hey, while we are at it why not do that...
> 
> I agree, it's an easy operation to do it so we should do it.  It's no major
> discomfort.  Note that you should always treat a string as an object anyway
> (and therefore serialize it before encrypting) because of limitations in the
> mcrypt functions.
> 
> > As for database "de-fanging" (eliminitating database unfriendly chars and 
> > char
> > sequences), I believe this should be handled at the SO level, as an 
> > example, the
> > preferences class that handles the storage and retrieval of email prefs 
> > from the
> > preferences table, has code in there to handle adding slashes, and 
> > serialization.
> > (I don't know how other apps handle their prefs)
> 
> OK, BUT:
> 
> -  The mcrypt functions will ONLY handle an object / string that has ALREADY 
> been
>    de-fanged.  It will ALWAYS return a string (in fact a binhex'ed string) 
> that
>    has been de-fanged, or in any case does not need de-fanging.
> 
> -  Since crypto will always return a de-fanged string when mcrypt is enabled, 
> why
>    not have it also always return a de-fanged string when mcrypt is disabled?
> 
> I agree that the encrypt & de-fang operations are logically orthogonal, 
> however in
> this case there is some benefit to having them combined due to the reliance 
> of one
> upon the other.
> 
> --
> Del
> 
> _______________________________________________
> Phpgroupware-developers mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/phpgroupware-developers

-- 

Miles Lott - http://milosch.net
phpGroupWare - http://www.phpgroupware.org