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

[Del]

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