Re: Core services design patern
Re: Core services design patern
- Subject: Re: Core services design patern
- From: Joe Little <email@hidden>
- Date: Tue, 2 Feb 2010 11:10:19 -0800
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@hidden> 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@hidden>
> To: "Cheong Hee (Gmail)" <email@hidden>
> Cc: "WebObjects-Dev Mailing List List" <email@hidden>
> 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@hidden>
> 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@hidden)
>> Help/Unsubscribe/Update your Subscription:
>>
>> This email sent to email@hidden
>>
>
>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden