[OWASP-ESAPI] IUser and RSAToken
Jim Manico
jim at manico.net
Mon Jan 7 21:13:22 EST 2008
> >a huge security anti-pattern?
>You mean like username and password?
I agree, the age of the password is dead. Pass*phrase* seems like the
minimum to me. Preferably some kind of multi-factor-auth (or at least
consumer banking's psudo-multi-factor).
To me, SOAP seems like some developer could not get an admin to open up
a new port, so hey, lets use port 80....
Now ignoring that, if ESAPI can handle some kind of *simple* abstracted
Credentials, that should put this entire conversation to rest. Hopefully
something easy for your every-day enterprise developer to deal with. I
still have nightmares from trying to deal with JAAS and the like.
- Jim
> >a huge security anti-pattern?
>
> You mean like username and password?
>
> -gp
>
>
> On 1/7/08 6:57 PM, "Jim Manico" <jim at manico.net> wrote:
>
> Isn't ws-trust SOAP specific - SOAP being (essentially) a huge
> security anti-pattern?
>
> - Jim
>
>
> Is there a reason you wouldn’t use ws-trust to do this? This
> is precisely why it was invented
>
> -support multiple token types – x.509 (if you are a sadist),
> saml (if you like xml), kerberos (if youlike dogs), and/or
> username/password (if you don’t really care about security),
> or invent your own token
>
> - simple request response methods to create a token and
> validate a token,
>
> -gp
>
> On 1/7/08 9:46 AM, "Jeff Williams" <jeff.williams at owasp.org>
> <mailto:jeff.williams at owasp.org> wrote:
>
>
>
> I’m thinking an enterprise would only want to have the
> authentication methods they’re actually using in **their**
> ESAPI. I don’t want an API that’s so generic that it’s
> impossible for any real developers to figure out and use.
> (I’ve got plenty of JAAS and JCE scars).
>
>
> But I like Stephen’s idea about using a Set of Credentials
> for the createUser and login method. This would let the
> API be used with a bigger range of authentication
> approaches without making it ridiculously abstract. I
> think we probably want to specify the type of the
> credentials, so ESAPI can know how to authenticate them.
>
>
> So it would work like this…
>
> - The parameter names for the credentials can be
> specified in ESAPI.properties.
>
>
> - ESAPI extracts credentials from the request and
> generate Credential objects
>
>
> - ESAPI compares the credentials against the ones in
> the User object.
>
>
>
> That’s not a huge stretch for ESAPI – it already works
> like this for username/password.
>
> Will that work to support the schemes you’re thinking of?
>
> --Jeff
>
>
> *From:* owasp-esapi-bounces at lists.owasp.org
> [mailto:owasp-esapi-bounces at lists.owasp.org]
> <mailto:owasp-esapi-bounces at lists.owasp.org%5D>
> <mailto:owasp-esapi-bounces at lists.owasp.org%5D> *On
> Behalf Of *Jim Manico
> *Sent:* Monday, January 07, 2008 3:23 AM
> *Cc:* owasp-esapi at lists.owasp.org
> *Subject:* Re: [OWASP-ESAPI] IUser and RSAToken
>
> Cool. Right on Stephen (and Dan) May I invite you to take
> this to the next level?
>
> How would you envision us going from a bunch of request
> data to hitting your suggested API?
>
> For example, here are a few situations I think we want
> work with
>
> *banking site:
> *username
> password
> question_id
> answer_text
> (and the user would see an image for phishing
> verification, but would not be sent, but would be needed
> at createUser time)
>
> *RSA token auth:
> *username
> password
> rsa_token_selection
>
> *standard enterprise app
> *username
> password
>
> Assuming these cases are consistent with what you are
> seeing, would you care to take your ideas a little deeper?
>
> Thanks folks,
> Jim
>
>
>
> I wasn't suggesting copying the whole implementation, just
> the bit about using an arbitrary number of Credentials per
> user. E.g.:
>
> public class Credential {
> String name;
> Object value;
> //getters and setters...
> }
>
> interface IUser {
> void addUser(String username, String otherStuff..,
> Set<Credential> creds);
> boolean login(Set<Credential> creds); //this compares
> the supplied set with the stored set
> }
>
>
> On Jan 7, 2008, at 9:02 AM, Jim Manico wrote:
>
>
>
> JAAS seems anything but intuitive to me - it's more for a
> servlet engine implementor or large commercial product.
>
> >From
> http://java.sun.com/javase/6/docs/api/javax/security/auth/spi/LoginModule.html
>
> initialize
> public void initialize(Subject subject,
> CallbackHandler callbackHandler,
> Map sharedState,
> Map options)
> Initialize this LoginModule.
> This method is called by the LoginContext after this
> LoginModule has been instantiated. The purpose of this
> method is to initialize this LoginModule with the relevant
> information. If this LoginModule does not understand any
> of the data stored in sharedState or options parameters,
> they can be ignored.
>
>
>
> Parameters: subject - the Subject to be authenticated.
> callbackHandler - a CallbackHandler for communicating with
> the end user (prompting for usernames and passwords, for
> example). sharedState - state shared with other configured
> LoginModules. options - options specified in the login
> Configuration for this particular LoginModule.
>
> Stephen de Vries wrote:
>
>
>
> I've not taken a close look at the ESAPI source, so I may
> be talking
> out of my 4rse here, but couldn't ESAPI use an arbitrary
> Set of
> credentials the way JAAS does?
>
>
> On Jan 7, 2008, at 5:27 AM, Jeff Williams wrote:
>
>
>
>
> Jim,
>
> Interesting. I'm trying to keep to just the methods that
> pretty much
> every
> web application or web service would have to have. But I
> definitely
> understand the need for specialized User objects in most
> enterprises. Do
> you think we can come up with a way to handle these
> options in a way
> that
> will be used in most apps?
>
> I strongly encourage customization of the ESAPI for your
> enterprise.
> Actually, I expect every enterprise will need their OWN
> ESAPI. I would
> expect extensions like the ones you've proposed to the API
> itself (the
> interfaces). And I expect them to rip, mix, and burn the
> reference
> implementation with their own services and internal needs.
>
> I'm focused on the challenge of getting enterprises to
> agree that they
> should define and institutionalize an ESAPI. If they use
> ours, or
> one based
> on ours, then great. But it's still great if they make up
> their own.
>
> --Jeff
>
> -----Original Message-----
> From: owasp-esapi-bounces at lists.owasp.org
> [mailto:owasp-esapi-bounces at lists.owasp.org]
> <mailto:owasp-esapi-bounces at lists.owasp.org%5D>
> <mailto:owasp-esapi-bounces at lists.owasp.org%5D> On Behalf
> Of Jim Manico
> Sent: Sunday, January 06, 2008 5:19 AM
> To: owasp-esapi at lists.owasp.org
> Subject: [OWASP-ESAPI] IUser and RSAToken
>
> Jeff,
>
> Many of the apps I'm writing for a certain large
> Enterprise involves a
> RSA token reference stored in the user profile. Would you
> suggest I
> extend the ESAPI user object, or would you consider
> integrating this
> into EASPI in some way?
>
> I'm thinking me might want a few different user types
> depending on the
> type of application:
>
> 1) StandardUser (user, pass only)
> 2) BankingUser (user, pass, map of auth questions,
> phishing image id)
> 3) EnterpriseUser (user, pass, rsa token identifier)
>
> In fact, there are several over User authentication
> possibilities (SSO
> tech, for example)
>
> And I moving in the wrong direction by bringing these
> issues up?
>
> - Jim
> _______________________________________________
> OWASP-ESAPI mailing list
> OWASP-ESAPI at lists.owasp.org
> https://lists.owasp.org/mailman/listinfo/owasp-esapi
>
>
> _______________________________________________
> OWASP-ESAPI mailing list
> OWASP-ESAPI at lists.owasp.org
> https://lists.owasp.org/mailman/listinfo/owasp-esapi
> _______________________________________________
> OWASP-ESAPI mailing list
> OWASP-ESAPI at lists.owasp.org
> https://lists.owasp.org/mailman/listinfo/owasp-esapi
>
>
>
>
>
>
>
>
> ------------------------------------------------------------------------
>
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.5.516 / Virus Database: 269.17.13/1211 - Release
> Date: 1/6/2008 11:57 AM
>
>
>
> ------------------------------------------------------------------------
>
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.5.516 / Virus Database: 269.17.13/1213 - Release Date: 1/7/2008 9:14 AM
>
--
Best Regards,
Jim Manico
VP Software Engineering, Codemagi Inc.
Application Security Instructor, Aspect Security
jim at codemagi.com
808.652.3805 (c)
484.259.3805 (f)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.owasp.org/pipermail/owasp-esapi/attachments/20080107/0eb69edb/attachment.html
More information about the OWASP-ESAPI
mailing list