[security] passing password on identification request?

[John Bradley]

Are you accepting 3rd party openIDs for your web app?

Most people don't have an objection to starting up a browser session  
to get user confirmation for oAuth.

Though there are ways to completely decouple that as well.

You can also have the website give the user a OTP for registering the  
app.

Asking the user to enter there openID and password into your app is a  
huge security violation, and not something that is likely to ever be  
supported.

John B.
On 2009-10-19, at 2:13 PM, Anthony Brassac wrote:

> I see, what's unfortunate is that openId was perfect for the needs  
> of our web application. Unfortunately it won't meet the requirements  
> of our web service, so we may actually choose to write our own  
> system now (seeing as how even oAuth needs manual logging in at some  
> point too). Though I'm surprised that we seem to be the only ones  
> with this problem, is that a technical challenge to make openId more  
> web service friendly or is that just a matter of time?
>
>
> On Mon, Oct 19, 2009 at 11:40 AM, John Bradley <ve7jtb at ve7jtb.com>  
> wrote:
> The user needs to approve the oAuth access somehow.  It only needs  
> to be a web browser if you want to use openID for that.
>
> Sorry for the bad news, but openID requires a browser at this point.
>
> If you are the authenticator for the account and not a third party  
> then there are lots of ways to solve your problem,  but you will  
> have to stretch to claim they have any connection to openID.
>
> John B.
>
> On 2009-10-19, at 12:28 PM, Anthony Brassac wrote:
>
>> But no matter what, even with oAuth I will need to log in using a  
>> web browser at some point in order to get that key/secret  
>> combination, won't i? Unless there are providers that offer  
>> programmatic log in?
>>
>> I have a feeling we are going to end up having to write something  
>> ourselves :S
>>
>>
>> On Thu, Oct 15, 2009 at 11:54 AM, John Bradley <ve7jtb at ve7jtb.com>  
>> wrote:
>> You can have the user authenticate to the oAuth provider via openID  
>> if it is a condition of the grant:)
>>
>> That may be the best way to do it anyway depending on how the app  
>> is configured.
>>
>> John B.
>>
>> On 2009-10-15, at 12:00 PM, Anthony Brassac wrote:
>>
>>> Thanks all for your replies, oAuth looks like it could do it for  
>>> us, however it seems management had agreed upon using OpenID  
>>> (research grant related I think), so I'll have to see what gives.  
>>> Anyway, I appreciate your support.
>>>
>>> On Wed, Oct 14, 2009 at 1:47 AM, SitG Admin <sysadmin at shadowsinthegarden.com 
>>> > wrote:
>>> Users giving there passwords to RPs is what openID is trying to  
>>> prevent.
>>> That is why passwords are not supported in the redirect.
>>>
>>> Hmm . . . minor clarification here, though: users giving passwords  
>>> *their passwords for the OP* (or otherwise transmitting "in the  
>>> clear") is not compatible with OpenID.
>>>
>>> If the RP wants to ask for another password (one local to that  
>>> system), e.g. for rarely invoked high levels of access, it *might*  
>>> be compatible with OpenID (depends on the exact use, but isn't  
>>> automatically NOT compatible).
>>>
>>> The description Anthony gave sounds vaguely like Kerberos (from  
>>> the MIT dialogue), but my mind is stuffed full of other things  
>>> right now and I get a bit of a headache just getting some meaning  
>>> out of roughly half of it (the rest seems beyond me tonight).
>>>
>>> -Shade
>>>
>>> _______________________________________________
>>> security mailing list
>>> security at lists.openid.net
>>> http://lists.openid.net/mailman/listinfo/openid-security
>>>
>>
>>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-security/attachments/20091019/b44de7e5/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2468 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-security/attachments/20091019/b44de7e5/attachment.bin>