Last call for input: Authorization API

13 views
Skip to first unread message

Anton de Winter

unread,
Sep 21, 2010, 6:08:53 PM9/21/10
to OpenRosa Working Group
Hi,


Please have a look at the Auth API doc and see if there are last minute issues you would like to discuss before the API gets put to a vote. In approx. 48 hours I'll be putting the API to a vote (procedure detailed here: http://groups.google.com/group/openrosa-workgroup/web/workgroup-procedures ) if there aren't any major issues.

Cheers!
Anton

Jonny Heggheim

unread,
Sep 22, 2010, 4:11:17 PM9/22/10
to OpenRosa Working Group
Hi!

Sorry for this late reply!

I don't see the need for supporting 3 different ways to authenticate.

Are there some requirements that basic authentication (+ optional
HTTPS) can't meet?


Jonny Heggheim
OpenXdata

On Sep 22, 12:08 am, Anton de Winter <adewin...@dimagi.com> wrote:
> Hi,
>
> http://bitbucket.org/javarosa/javarosa/wiki/AuthorizationAPI
>
> Please have a look at the Auth API doc and see if there are last minute
> issues you would like to discuss before the API gets put to a vote. In
> approx. 48 hours I'll be putting the API to a vote (procedure detailed
> here:http://groups.google.com/group/openrosa-workgroup/web/workgroup-proce...)

Yaw Anokwa

unread,
Sep 22, 2010, 4:33:01 PM9/22/10
to openrosa-...@googlegroups.com
hey jonny,

basic auth sends passwords in cleartext. we had an earlier discussion
about this at http://groups.google.com/group/javarosa-developers/browse_thread/thread/d7972bcc4719d9fb

yaw

Anton de Winter

unread,
Sep 22, 2010, 4:37:53 PM9/22/10
to openrosa-...@googlegroups.com

Mitch Sundt

unread,
Sep 22, 2010, 4:41:39 PM9/22/10
to openrosa-...@googlegroups.com

Hi Jonny,

The spec defines only one scheme that the device must implement -- a subset of the DigestAuth specification using MD5 hash and a qop of either "omitted" or "auth" (both are required to be implemented).  The differences between these is minor --  the "omitted" variant has security holes that the "auth" variant closed -- and it should generally be avoided.  As far as I'm concerned, "omitted" is in the spec because I don't know what the state of support is for the "auth" variant in all the webserver containers (e.g, Tomcat, Glassfish, Jetty, etc.)

As others have responded, the key problem with BasicAuth is that there are numerous points where wireless eavesdroppers could listen to your data transmissions (e.g., unsecured wireless hotspots, physically non-secure networks).  Since many people lack the knowledge, skill or physical environments to secure their networks, if we support BasicAuth, we should then require all authenticated communications be sent via HTTPS.  That is what we are attempting to avoid by requiring DigestAuth.

Mitch
--
Mitch Sundt
Software Engineer
http://www.OpenDataKit.org
University of Washington
mitche...@gmail.com

Jonny Heggheim

unread,
Sep 22, 2010, 4:45:33 PM9/22/10
to openrosa-...@googlegroups.com
Hi Yaw!

HTTPS will not send the password as clear text!


Jonny

Jonny Heggheim

unread,
Sep 22, 2010, 5:05:59 PM9/22/10
to openrosa-...@googlegroups.com
Hi Mitch!

> As others have responded, the key problem with BasicAuth is that there are numerous points where wireless eavesdroppers could listen to your data transmissions (e.g., unsecured wireless hotspots, physically non-secure networks).  Since many people lack the knowledge, skill or physical environments to secure their networks, if we support BasicAuth, we should then require all authenticated communications be sent via HTTPS.  That is what we are attempting to avoid by requiring DigestAuth.

I totally agree! Maybe my wording should be; HTTPS is required.

Btw, how would you secure the transmissions of the collected data via
DigestAuth?


Jonny

Brent Atkinson

unread,
Sep 22, 2010, 5:17:29 PM9/22/10
to OpenRosa Working Group
Yaw,

Unfortunately digest *requires* that the raw user credentials in order
to build the hash. For projects that are only storing one way hashes,
this requires they subvert all that. I'm not a member of the group so
I can't read the discussion threads, but how does security of the
payload tie into this? That digest scheme isn't much protection these
days, so the trade-off seems a little weak - especially considering
that the payloads are still left unprotected.

Brent


On Sep 22, 4:33 pm, Yaw Anokwa <yano...@gmail.com> wrote:
> hey jonny,
>
> basic auth sends passwords in cleartext. we had an earlier discussion
> about this athttp://groups.google.com/group/javarosa-developers/browse_thread/thre...

Jonathan Jackson

unread,
Sep 22, 2010, 5:49:07 PM9/22/10
to openrosa-workgroup
Brent - 

Can you clarify why digest requires the raw credentials to be stored?  I was under the impression that they were required to generate the hash once with a known salt.  I did not think you had to constantly keep them in raw form.  I agree if you do, that would be an unacceptable scheme.

Jonny - 

Using HTTPS is definitely recommend (and required depending on your legal environment).  However, encrypted the payload beyond what https does is arguably not making it any more secure if you are going to store that payload on disk or in a database in an unencrypted format.  Sending the password in plain text over https is less secure because you typically do not store the plain text password anywhere in the system.  

-J

Jonny Heggheim

unread,
Sep 22, 2010, 6:19:19 PM9/22/10
to openrosa-...@googlegroups.com
Hi Jonathan!

> Using HTTPS is definitely recommend (and required depending on your legal
> environment).

Sounds great!

>However, encrypted the payload beyond what https does is arguably not making it any more secure if you are going to store that payload on disk or in a database in an unencrypted format.

I thought this API discussion was about authentication (and
transmission of data) and not about storage. Is this off-topic or is
it something we should consider?

> Sending the password in plain text over https is less secure because you typically do not store the plain text password anywhere in the system.

The above statement is also about storage. But I am curious to know
who stores passwords as plain text?

For example, in OpenXdata all user passwords are stored as SHA1 hash
including a random salt, we never store the password as clear text.


Jonny

Mitch Sundt

unread,
Sep 22, 2010, 6:21:52 PM9/22/10
to openrosa-...@googlegroups.com
If you need to secure the data, you would do it over a HTTPS pipe. 

The user's password would be held in memory in the device's application, but not stored anywhere on the phone's sdcard or flash.  I would expect the application to prompt for the user's password each time it is launched.  Note that if you did just Basic Auth, you would still need to hold the password in memory, as each request would send the password, in plain text, over the wire.

While medical applications would require securing the data transmissions with HTTPS, there are a number of other application areas, such as wildlife surveys, where you simply want to ensure that the submitter is authenticated and authorized to submit the form.  That prevents malicious submissions and provides identities of the submitters for survey management.

Other transmissions also don't need HTTPS security in practice, such as:
- getting the list of forms
- downloading form definitions and associated media files (e.g., training videos, images, etc.)
- synchronizing configuration files

For these, it is desirable to know who is requesting the data in order to simplify the choices displayed to a less-trained device user and to do remote phone management (ensuring that user X has the forms and phone configuration they need to do their job).

Generally, these transmissions don't *require* authentication, but do benefit from having the identity of the requester.

Finally, in all these cases, having all requests authenticated mitigates some of the impacts of DoS or other attacks -- it is less burdensome to verify and deny a failed authentication than to blindly set up the streaming of a multi-megabyte video file, and consume resources due to maliciousness.

------------
Mitch

Simon Kelly

unread,
Sep 23, 2010, 3:11:14 AM9/23/10
to openrosa-...@googlegroups.com
I think what Brent was saying here is that the raw user credentials are required to verify the hash sent by the client i.e. the server needs access to the raw credentials. This poses a problem for servers like OpenXData, OpenMRS that store passwords as salted hashes. I think this did come up in a previous dicussion but I don't recall it ever being resolved.

--
Simon Kelly
Technical Manager
Cell-Life
Cape Town, South Africa
+27 (0) 21 469 1111
+27 (0) 21 469 1126 (fax)
+27 (0) 72 231 0096 (mobile)
www.cell-life.org

Brent Atkinson

unread,
Sep 23, 2010, 8:58:55 AM9/23/10
to openrosa-...@googlegroups.com
Yes,

Simon you understood me correctly. The problem with the digest scheme is that in order to verify that the credentials are valid the server needs to build the same hash. To do that it must know the username, password and realm. This implies that the server must have visibility of the user's password. This is something that many modern software systems spend significant effort to avoid and would require them to take a step backwards security-wise in order to be compliant (if it's required to be compliant).

Jonny: You are correct that you can store the hash, but you'll have to generate and store it for every realm for every user. If you add a realm or change the name and wish to authenticate an existing user, you will require the username and password again to generate and store the new hashes. So, in general, you need the raw credentials on the server if you don't want to require strange work flows on users and administrators.

Brent
--
---
Brent Atkinson
brent.a...@gmail.com

Mitch Sundt

unread,
Sep 23, 2010, 12:56:19 PM9/23/10
to openrosa-...@googlegroups.com
Ah.  This is a question I've had about the server side as we try to implement the authentication layers, particularly LDAP (something that we just have prototyped now).  The best description of the process that I have found is at http://docs.moodle.org/en/LDAP_authentication

From this, it sounds like the LDAP system itself can be configured to store the passwords as plaintext, MD5 or SHA-1 hashes.  This would mean that the server would need to communicate in its Auth challenge to the client that it requires either the plaintext password, a MD5 hash of it, or SHA-1 hash to be used when constructing up the DigestAuth hash.  Otherwise the authentication hash cannot be verified.

So perhaps we need an additional header in OpenRosa compliant messages, "X-OpenRosaPasswordTreatment" with a value of "MD-5", "SHA-1" or "plaintext" ?

So that the device knows how to form the hash?

Mitch

Mitch Sundt

unread,
Sep 23, 2010, 12:58:06 PM9/23/10
to openrosa-...@googlegroups.com
The question then, too, is -- do any systems do anything more funky than MD5 hashes or SHA-1 hashes of the raw password?  Does anyone add static strings before or after the password before doing the hash?

Mitch

Clayton Sims

unread,
Sep 23, 2010, 12:58:23 PM9/23/10
to openrosa-workgroup
On Wed, Sep 22, 2010 at 11:17 PM, Brent Atkinson <brent.a...@gmail.com> wrote:
Yaw,

Unfortunately digest *requires* that the raw user credentials in order
to build the hash. For projects that are only storing one way hashes,
this requires they subvert all that.

This point comes up a lot WRT using digest authentication, and it's fully disingenuous. _Every_ form of authentication requires the user credentials on the first run to generate the hash. The only advantage to using some other hash is that many systems already hashes in that format, which shouldn't enter into the argument about what auth scheme is best for our purposes. We should be assuming that systems will be able to request the user re-enter their password, authenticate it against their current one if necessary, and store the new hash for whatever scheme we use.

To be super clear here:
Digest authentication only requires the server to build the user's HA1 hash once, using their username and password (which can be done on the client side, never sending the server the plaintext) the same way making an SHA1 happens per user. 

On Thu, Sep 23, 2010 at 8:58 AM, Brent Atkinson <brent.a...@gmail.com> wrote:
Jonny: You are correct that you can store the hash, but you'll have to generate and store it for every realm for every user. If you add a realm or change the name and wish to authenticate an existing user, you will require the username and password again to generate and store the new hashes. So, in general, you need the raw credentials on the server if you don't want to require strange work flows on users and administrators.

This is a feature, not a drawback of digest authentication. It means that when a user provides their credentials to a server, they are locking the server into not being able to change them, or transport them elsewhere. The point of digest authentication is that the shared secret required by the client and the server is already a one-way function of their credentials and the point of authentication. 

-Clayton 

Clayton Sims

unread,
Sep 23, 2010, 12:59:46 PM9/23/10
to openrosa-workgroup
Digest authentication supports a header in the WWW-Authenticate request that includes the Hash algorithm that should be used (in practice, if not fully in the specification).

-Clayton

Brent Atkinson

unread,
Sep 23, 2010, 1:32:03 PM9/23/10
to openrosa-...@googlegroups.com
Clayton,

Forgive my ignorance, but I don't understand how your response is pertinent. Obviously, credentials are required at first. To my knowledge no one has asserted otherwise. The issue is with whether username and more importantly password are required past that point. Because the HA1 is based on the realm name, you'd have to ask *all* users to re-enter their passwords just to do something simple like change a realm name or adding existing users to a new realm. You can get around this if you keep the username and passwords on the server side. When you change or create new realm names you could then regenerate the hashes. However, if you are storing the usernames and passes like this, storing the hashes has no security benefit, it would just be for performance. Now, if you say you assume a single immutable realm name for any openrosa system, then I agree they are equivalent with other schemes. But then, why is realm included?

Brent

Jonathan Jackson

unread,
Sep 23, 2010, 1:56:24 PM9/23/10
to openrosa-workgroup
Hi Brent,

I think part of Clayton's point is that saying, "We don't want to go this way because we don't want to rehash the password" is not a good argument against digest because it would be the same if we standardized on SHA1 and you were storing in MD5.  

I believe there were assertions that to practically implement this in a useful way you need to keep the password stored in plain text on the server side, but I don't think that's true based on the previous arguments.

You always need to ask all the users to re-enter their password if you want to update your hashing scheme.  I don' t think that's a fundamental issue.  You can do that lazily and any good back-end architecture should assume you may need to do this to inter operate with other systems.   

Also, even if we do have a global realm, or you only want to support a global realm, it still provides the handshake in an industry standard way.  

-J

Clayton Sims

unread,
Sep 23, 2010, 1:57:03 PM9/23/10
to openrosa-workgroup
Changing the realm name should require re-acquiring authentication credentials. You shouldn't ever change the realm name unless you're migrating to a fundamentally new service, users provide their credentials for your realm, not for anyone else's, the realm name is the token that lets users know who they're providing credentials to. Taking people's old credentials and adding them to a new realm is basically saying "We've taken your account details and signed you up automagically on our new service, come log in!" which is a violation of user trust.

Agreed that no OpenRosa server should ever store the user's credentials, only the HA1 hash. And I don't think that there should be a single immutable realm, there should be different realms for each deployment. That gives users confidence that their credentials are stored and manged in a limited scope. This is akin to the reason that you need an account on every new Google service, despite them having your credentials: you shouldn't ever sign users up for anything they didn't explicitly provide credentials for, for both security reasons (stealing someone's HA1 hash on ODK aggregate should also give you access to their CommCare HQ account) and for user privacy reasons (The "their credentials, not yours" philosophy).

-Clayton

Clayton Sims

unread,
Sep 23, 2010, 2:24:36 PM9/23/10
to openrosa-workgroup
So just to clarify a few points about HTTPS+Basic Auth stuff inline:

On Wed, Sep 22, 2010 at 6:19 PM, Jonny Heggheim <heg...@gmail.com> wrote:
> Using HTTPS is definitely recommend (and required depending on your legal
> environment).
Sounds great!
 
Yup, HTTPS should definitely be used wherever possible. (Most servers should require it)


>However, encrypted the payload beyond what https does is arguably not making it any more secure if you are going to store that payload on disk or in a database in an unencrypted format.
I thought this API discussion was about authentication (and
transmission of data) and not about storage. Is this off-topic or is
it something we should consider?
 
Absolutely agree that the Auth API and any device storage should be completely disconnected discussions
 

> Sending the password in plain text over https is less secure because you typically do not store the plain text password anywhere in the system.
The above statement is also about storage. But I am curious to know
who stores passwords as plain text?

For example, in OpenXdata all user passwords are stored as SHA1 hash
including a random salt, we never store the password as clear text.

Storing as an SHA1 hash on the server is a completely legitimate thing to do, and receiving the password in plaintext and hashing it into a hash to compare it is definitely secure in the sense that HTTPS+sending the credentials will not result in the password ever being exposed over the wire. However, there are multiple attacks which make this scheme vulnerable

1) Basic Auth credentials rely on the server that the user is communicating with to be be the correct one, with no verification. If you ever send the wrong server or are in a local network where there is a Man-in-the-middle on the DNS, there is no way to prevent that server from simply replying to any request with a WWW-authenticate response and collecting your plaintext credentials. If a user is on ODK using WIFI, and the router redirects traffic to another computer on the subnet, which gives a 401 response, that computer will _automatically_ get your username and password. This is especially a concern for our users who are in foreign countries where the government has the capacity to manipulate APN endpoints (this has been expressed as a concern by potential users in both China and Zimbabwe).

2) Basic Auth also relies on the server to be uncomprimised at a traffic level. If your server has been compromised at a network level (which is fairly easy compared to a database level), logging the incoming apache (or other server) traffic will give you everyone's user credentials.

3) In Basic Auth, authentication sessions are global and unending (there is no 'login' requiring active input from the user, merely the same token used for every request). The server can't expire local tokens to require re-authentication, meaning that it can have no confidence in the auditability of incoming data records from a HIPAA or other minimum-security-environment regulations.

Mitch Sundt

unread,
Sep 23, 2010, 2:24:58 PM9/23/10
to openrosa-...@googlegroups.com
There's the algorithm tag, which specifies the overall hash mechanism (i.e., MD5), but I don't see anything that says whether the A1 value (RFC 2617 section 3.2.2.2 http://www.apps.ietf.org/rfc/rfc2617.html#sec-3 ) used in the construction should be:

A1 = unq(username-value) ":" unq(realm-value) ":" passwd

or

A1' = unq(username-value) ":" unq(realm-value) ":" MD5(passwd)

or

A1'' = unq(username-value) ":" unq(realm-value) ":" SHA-1(passwd)

I think that is where the concern is -- the LDAP systems seem to offer storage of the password as plaintext, SHA-1, or MD5, and if stored as MD5, only a DigestAuth using A' would validate.

Mitch

Brent Atkinson

unread,
Sep 23, 2010, 2:28:35 PM9/23/10
to openrosa-...@googlegroups.com
Jonny: I don't think that is an accurate description of the argument I'm presenting.

Clayton: From http://tools.ietf.org/html/rfc2617#section-4.13 it seems that realm is intended for limiting the scope of vulnerability when password files are compromised.

 I didn't raise this up to argue about digest vs. another scheme. I am more concerned that the implementation can be mapped onto common application architectures. It is very common to want to manage user credentials per user (as opposed to the combination user and realm) and membership in a service orthogonally. If this scheme requires significant effort to implement on such systems and you require it for compliance, I'm skeptical it will be adopted.

Brent

Clayton Sims

unread,
Sep 23, 2010, 2:30:33 PM9/23/10
to openrosa-workgroup
Forgot one more thing

In places where HTTPS is unavailable (for either legal reasons, as in Burma/China etc, or for strange practical reasons like a super strange environment where the client doesn't have a TLS channel capacity), secure authentication shouldn't _also_ become impossible. For a lot of our users, the need for the data to be secure is minimal (The data isn't important), but the ability to audit data being submitted by an authorized user is important. In those environments, the HTTPS negotiation overhead is rough due to super-low throughput rates on the GPRS channel (Overall communcation bandwidth is low, but it's a chatty negotiation process), so being able to send plaintext submissions with authorized credentials is a nice thing to have.

-Clayton

Mitch Sundt

unread,
Sep 23, 2010, 2:36:11 PM9/23/10
to openrosa-...@googlegroups.com
From section 3.2.1 of RFC2617:
 realm
     A string to be displayed to users so they know which username and
     password to use. This string should contain at least the name of
     the host performing the authentication and might additionally
     indicate the collection of users who might have access. An example
     might be "register...@gotham.news.com".
Section 4.x of the spec outline security concerns with the authentication mechanism, and don't imply any required implementation.  The point of that section is that a file containing all data for a given realm would compromise access to that realm.  That the A1 hash includes the realm as part of the hash, so it limits the compromise to just that realm.

Mitch

Clayton Sims

unread,
Sep 23, 2010, 2:45:46 PM9/23/10
to openrosa-workgroup
On Thu, Sep 23, 2010 at 2:28 PM, Brent Atkinson <brent.a...@gmail.com> wrote:
Clayton: From http://tools.ietf.org/html/rfc2617#section-4.13 it seems that realm is intended for limiting the scope of vulnerability when password files are compromised.

Right, if a user provides their credentials to your realm they shouldn't also be providing their credentials universally. Realm is intended to provide a scope of authentication for both the users and the server so that adversaries who gain access to one don't gain access to all of them.

 I didn't raise this up to argue about digest vs. another scheme. I am more concerned that the implementation can be mapped onto common application architectures.

Digest authentication is readily available on ~all server environments, and JavaRosa contains an implementation for J2ME clients which took about a day to write (it is extraordinarily rare for a platform to not support digest auth with a simple library, j2me is very much the exception). 

It is very common to want to manage user credentials per user (as opposed to the combination user and realm) and membership in a service orthogonally. If this scheme requires significant effort to implement on such systems and you require it for compliance, I'm skeptical it will be adopted.

Implementing digest authentication simply requires servers to be capable of requesting users to enter their password again (once for the initial login, and once anytime the realm is compromised and the server needs to generate new credentials). In the steady state, this requires only one password entry phase, which I'm unconvinced is onerous for developers. It requires developers to manage user credentials more carefully and in a more limited way (per 'realm'), but this mostly just means that you can't move users between servers that don't share a realm.

Also, compliance in an Auth standard also means that we should be comfortable directing our users to use other systems interoperably. I'd be uncomfortable directing our users to use any of the secure tools to communicate with a server which didn't implement authentication at a level which provided the benefits that digest auth does. Especially if convenience of moving user credentials around between servers was the reason, since that introduces inherent security problems. 

Brent Atkinson

unread,
Sep 23, 2010, 2:57:11 PM9/23/10
to openrosa-...@googlegroups.com
Clayton,

Assuming an application only exposes a single realm, the hashes can be managed similarly to existing schemes. This doesn't bother me so much anymore. I'm aware that digest isn't difficult to implement from a technology standpoint, but that wasn't a concern. Dictating a particular user management system is a little heavy handed and uncommon for interop specs (in my experience). But, in the interest of moving things along I am willing to concede and will retreat back into my cave.

Thanks for sticking with me on this,

Brent

Jonny Heggheim

unread,
Sep 23, 2010, 3:17:34 PM9/23/10
to openrosa-...@googlegroups.com
Hi Clayton!

> Digest authentication is readily available on ~all server environments, and
> JavaRosa contains an implementation for J2ME clients which took about a day
> to write (it is extraordinarily rare for a platform to not support digest
> auth with a simple library, j2me is very much the exception).

Supporting digest on the OpenXdata server would force us to make major changes.
I don't know what changes OpenMRS, DHIS and different LDAP servers
etc. are forced to do if they choose to adopt the current OpenRosa
Authentication API.

My main concern is that we will get less OpenRosa compliant servers
(and maybe clients) if we push this API though.


Jonny

Jonny Heggheim

unread,
Sep 23, 2010, 3:19:02 PM9/23/10
to openrosa-...@googlegroups.com
Hi Clayton!

> Digest authentication is readily available on ~all server environments, and
> JavaRosa contains an implementation for J2ME clients which took about a day
> to write (it is extraordinarily rare for a platform to not support digest
> auth with a simple library, j2me is very much the exception).

Supporting digest on the OpenXdata server would pose a big impact.
I don't know about what impact OpenMRS, DHIS and different LDAP
servers etc. would implement this on their servers.

My main concern is that we will get less OpenRosa compliant clients
and servers if we force them to make big changes in their system.
OpenRosa 1.0 more advanced than needed.


Jonny

Jonny Heggheim

unread,
Sep 23, 2010, 3:22:24 PM9/23/10
to OpenRosa Working Group
Please ignore this last post, it was just a draft.


Jonny

Clayton Sims

unread,
Sep 23, 2010, 3:43:27 PM9/23/10
to openrosa-workgroup
Jonny,

Can you elaborate on the concrete difficulties that would be faced to get OpenXData capable of utilizing digest authentication? Given how simple it was to get digest auth working on j2me with ~no support from the environment, I feel like it should be possible pretty easily to support digest auth on a normal Java based server. 

I'm sure the community could provide resources to overcome any difficulties that would be faced in different server environments if groups think they would pose a particular burden for implementing them on their system. Especially since we eventually want to standardize of the methods by which user credentials are registered and managed if possible

-Clayton

Clayton Sims

unread,
Sep 23, 2010, 3:54:48 PM9/23/10
to openrosa-workgroup
Brent,

You're absolutely right that we should try to avoid over specifying or over-reaching the intent of each of the API's. I agree that we shouldn't be directly dictating things like what a user is, or how their model/credential is stored, manipulated, or managed in particular. It's definitely something we should be careful to not include directly in the API. If a group of tools want to use a single realm to simplify user registration or management between systems, that should absolutely be supported using the OpenRosa standard. I just don't want to lose the medium-strength security capabilities that we get from digest auth in order to encourage that kind of user management on the back-end.

And I apologize if my approach came off somewhat aggressive on those points. I came into this discussion from the perspective that there was a notion (stated to me by others as a result of conversations) that digest auth was less secure because one "needed" to store plaintext values (to be able to dynamically build A1 hashes), which I wanted to make sure wasn't a factor for anyone's approval of the API (since the debate should be focussed on user portability in that case, not security). I hope I didn't come off as dismissive of the notion overall that other Auth schemes had merits worth balancing and debating.

-Clayton

Brent Atkinson

unread,
Sep 23, 2010, 4:30:46 PM9/23/10
to openrosa-...@googlegroups.com
Clayton,

No problem, I like heated debates as long as they converge to meaningful conclusions.

:D

Mitch Sundt

unread,
Sep 24, 2010, 12:53:31 PM9/24/10
to openrosa-...@googlegroups.com
Can anyone comment on this?  I think this might be a core issue in backend LDAP integration.

Jonny Heggheim

unread,
Sep 25, 2010, 7:11:09 AM9/25/10
to openrosa-...@googlegroups.com
Hi again, I just arrived back in Norway.

Minor issues for OpenXdata server:
* Maintaining an extra authentication scheme.

Major "specification lock-in" problems:
Digest dictate how we store users passwords and that makes it harder
to share login with other 3rd party systems.
* What LDAP servers support or will support the OpenRosa Authentication API?
* What if OpenXdata users are stored in another appliaction (ex;
OpenMRS or DHIS)?

in contrast, OpenRosa with basic authentication would just be another
view/client on top of OpenXdata server.


Jonny

Jo Størset

unread,
Sep 28, 2010, 7:08:17 AM9/28/10
to openrosa-...@googlegroups.com
Hi,

I'm not really affiliated with openROSA, as of now, and I've only briefly read through the discussions, but thought I'd share some thoughts from a DHIS perspective (or maybe more accurately from my own perspective, working on dhis and mobile :).

Johnny wrote:

> Major "specification lock-in" problems:
> Digest dictate how we store users passwords and that makes it harder
> to share login with other 3rd party systems.
> * What LDAP servers support or will support the OpenRosa Authentication API?
> * What if OpenXdata users are stored in another appliaction (ex;
> OpenMRS or DHIS)?

As http digest incorporates the *web* server realm, it is not practically possible to use any form of centralized user management (LDAP/AD) on the server side with this mechanism. You will quickly be forced to have a separate user db for the single app (if security policies allow you), giving better "technical" security than with basic, but at the cost of worse security at a higher level (and you'll find that in "enterprise" environments you might have to follow their security policies rather than a spec like this).

On the other hand, I'm not convinced that a little security over the wire really is that much better than not hashing the passwords on the server side (which digest effectively makes impossible - you can have a static realm and store the user:realm:pass hash, but then what you store is effectively the secret needed to log in to the server with digest, anyway).

The only way to really move further with security is to implement third-party authentication mechanisms (OAuth, SAML), and in time effort could probably be put into that also for mobile clients (and maybe by allowing some kind of way to additionally allow better auth mechanisms in the spec?).

But for now, I really don't see the point in ruling out basic auth. It is really easy for a client to support basic if it already supports digest, it is not necessarily possible for a server to support digest. I think a spec like this should maximize interoperability, not so much force security on implementations.

At least, I am pretty sure I won't be able to make existing implementations of DHIS reinitialize all their users, even if I could convince the developers of changing the auth mechanisms. And I certainly won't be able to make big organizations change their infrastructure and policies to follow this spec (read centralized user db). So I think from a dhis point of view, we would have to choose to be non-compliant, as it is now.

My 2 paisa (hope I don't step on anyones toes :)
Jo

Jonathan Jackson

unread,
Sep 28, 2010, 8:45:37 AM9/28/10
to openrosa-workgroup
Hi Jo,

Thanks for the good feedback, its a helpful perspective.  I think we may want to implement more standards in the future such as OAuth or SAML, and agree a registry based user id scheme is ideal, but I don't know that the mobile teams have the time to do so now.  My argument against basic auth, which could be flawed, is that its difficult to make HIPAA compliant so likely a non-starter for any project seeking to work in the US.  Many hardened server deployments log every web access, the web log would contain exposed user passwords.  How do you get around this today on DHIS if you allow basic auth?  

Also, you can implement this transparently if you are allow users to valid in plain text today, because you can create the hash on the fly for users over some period of days (say 90).  And, if they didn't sign on during that period, you would have to request they input the password twice in a row, one time (which they are going to have to do anyways since they almost definitely forgot the password if they haven't logged in for 3 months).  

So, this is not saying OpenRosa won't support OAuth or SAML in the future, but that we are trying to make an incremental step in the right direction.  All that said, I do think that some servers may not choose to not to implement OpenRosa compliant specs for a variety of reasons; if I may inquire further, are you saying that DHIS would try to become OpenRosa 1.0 if Basic was an available option (including implementing the 5 other APIs as well) but not if Digest is required?  

Cheers,
Jonathan 

Jo Størset

unread,
Sep 28, 2010, 12:31:53 PM9/28/10