Don't know. SHA-1 is still safe for certain applications -- I think dig signatures is fine. But not for authentication.
On Sun, Jan 31, 2010 at 9:20 PM, Cheong Hee (Gmail) <[email protected]> wrote: > Thanks! Do you think secured email S/MIME should follow the same too, e.g. > sha256+rsa? I have this email signing module that is using sha1rsa as > combination. The concern is some platforms are still not SHA-2 ready yet. > > Cheers > > Cheong Hee > > ----- Original Message ----- From: "Joe Little" <[email protected]> > To: "Cheong Hee (Gmail)" <[email protected]> > Cc: "WebObjects-Dev Mailing List List" <[email protected]> > Sent: Sunday, January 31, 2010 1:00 AM > Subject: Re: Core services design patern > > > FYI, SHA-1 is broken. Need to use a SHA-2 variety, such as SHA-256. > Just need to store 56-byte Strings and use "SHA-256" in the digest > instantiation. > > > On Thu, Jan 28, 2010 at 9:19 PM, Cheong Hee (Gmail) <[email protected]> > wrote: >> >> Coincidentally, I have completed a small framework on this same request >> from >> customer. It is a pure java framework since it is aimed to be portable to >> any application e.g. Broadvision, WO. Quite similar that it creates new >> user password, authenticates user/password and returned error messages. It >> also has the user capabilities on the access module level. I used "Sha-1", >> and I thought it should be good enough for hash algo. Is it secured >> enough? >> Otherwise, I could change to DES/3DES/ MD4/5 etc. >> Just 2c. >> >>>>> I've got multiple web applications that share some common users. >>>>> I was thinking about creating a core user application to provide the >>>>> authentication service. Basically I'd like my "client" applications to >>>>> forward the login and password to this core user app and get either >>>>> "succeed" or "fail" (maybe a broader range of fail messages). >>>>> I don't really need the entire user to be stored directly in the >>>>> "client" apps, but I would sometimes need some attributes from the user >>>>> object. >>>>> >>>>> My though was: >>>>> -to create a framework to store an abstract class for the user >>>>> -to extend this class within the core user app (basically just make >>>>> them >>>>> non-abstract) >>>>> -to use the abstract class in the client apps (and eventually make only >>>>> a couple attributes non-abstract at that level) >>>>> >>>>> That way I could make sure my object is really the same throughout the >>>>> apps, at least they share a commun set of attributes. >>>>> A client app could request a login for a user and store only a subset >>>>> of the user. >>>>> >> >> _______________________________________________ >> Do not post admin requests to the list. They will be ignored. >> Webobjects-dev mailing list ([email protected]) >> Help/Unsubscribe/Update your Subscription: >> http://lists.apple.com/mailman/options/webobjects-dev/jmlittle%40gmail.com >> >> This email sent to [email protected] >> > > _______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [email protected]
