[twitter-dev] Re: OAUTH: Basic Auth is simpler/more reliable/more secure/better received than OAuth!?
Personally I've found JavaScript based auth systems like Facebook Connect and Google Friend Connect to be very difficult to debug and use. I am also a lot more comfortable with PHP then JS. As far as UX. Sign in with Twitter has the same flow as FBC and GFC. Click a link on your site, jump to provider to authorize, and return to consumer. Abraham On Thu, Jul 30, 2009 at 22:12, Jesse Stay jesses...@gmail.com wrote: I understand the reasoning behind OAuth, and think it's a step in the right direction, but, does Twitter have plans to improve and move to a better Auth system than OAuth? With Facebook Connect I just have to click once, and if the user is already logged in and approved my app, they never see the Facebook login box again. Where as with Twitter there are 3 points of potential failure every single time the user logs in. It's a Ux nightmare, IMO. While it does solve a problem, I don't think OAuth is the end or ideal solution. Are there plans to improve this process? Jesse On Wed, Jul 29, 2009 at 1:05 PM, Doug Williams d...@twitter.com wrote: Well said, Duane. Thanks, Doug On Wed, Jul 29, 2009 at 7:18 AM, Duane Roelands duane.roela...@gmail.com wrote: First, let me state from the start that I am no fan of OAuth, Twitter's implementation of it, or the way that they've behaved with regard to it. Now, with all that being said. If your website expects me to hand over my Twitter password, I'm not using your web site. Just yesterday, another scam site (TwitViewer) managed to steal thousands of accounts, and convince other people to hand over their information because it was posting tweets from the stolen accounts. OAuth is not perfect, but it provides individual users and Twitter with a way to identify bad actors and lock them out of the ecosystem. OAuth works. There are examples out there. There are developers who are willing to help you. Implementing OAuth tells your customers that the security of their account is important to you, and shutting down Basic Auth trains your users to stop giving away their password. If your product has value, and you clearly communicate what that value is, the users will use OAuth. On Jul 29, 9:10 am, Dewald Pretorius dpr...@gmail.com wrote: It would not surprise me at all if using OAuth resulted in fewer signups. Potential technical advantages of OAuth aside, every additional click that you add in the conversion process adds an addition leakage point where some users can and will abandon the signup process. -- Abraham Williams | Community Evangelist | http://web608.org Hacker | http://abrah.am | http://twitter.com/abraham Project | http://fireeagle.labs.poseurtech.com This email is: [ ] blogable [x] ask first [ ] private. Sent from Madison, Wisconsin, United States
[twitter-dev] Re: OAUTH: Basic Auth is simpler/more reliable/more secure/better received than OAuth!?
On Jul 31, 4:37 am, Duane Roelands duane.roela...@gmail.com wrote: OAuth lets you access the Twitter service without giving your Twitter credentials to anyone but Twitter. Basic Auth requires you to give your Twitter credentials to someone other than Twitter. Therefore, OAuth is more secure than Basic Auth. This is not rocket science. I agree with Bradley. It's how you (user) see the situation, but the situation is not that way. You do give password to application (or application can take it if it wants). You are just fooling yourself, and this makes security even worser. With basic auth you are aware of the fact you are giving application credentials, so are able to make thoughtful decision. With OAuth you (ordinary user) are not aware of the fact that you give application credentials, so you are under wrong illusion that you may use any application and you on the safe side. In reality you give application everything when installed it to your computer. In this situation basic auth becomes more secure because it shows situation to a user as it is (stupid! you must trust any application you are installing!), OAuth panders security threats (relax, you may think as if you may not trust the application, because you are as if not giving it credentials). -- Dmitriy V'jukov
[twitter-dev] Re: OAUTH: Basic Auth is simpler/more reliable/more secure/better received than OAuth!?
On Jul 30, 7:40 pm, Bradley S. O'Hearne brad.ohea...@gmail.com wrote: 2. Passwords being stored locally. Comment: The application integrating with Twitter is already effectively trusted, so the concern should not be with the app itself. The concern here would be other apps or people being able to grab passwords off of disk where stored. Again, I think this goes back to encryption. If all credentials are encrypted locally, then again, the concern becomes the breaking of encryption, and if that is done, then again whatever app or session token represents the key to the city can be acquired to use in OAuth too, if I'm not mistaken. Note that with basic auth it's perfectly possible to store only indirect security token too. Assume: application asks user for credentials, verifies them on the server, in response server issues unique indirect security token, application discards original credentials and stores token. This will depend on the application's security culture, though. -- Dmitriy V'jukov
[twitter-dev] Re: OAUTH: Basic Auth is simpler/more reliable/more secure/better received than OAuth!?
I am surprised nobody is bringing up these too points: - people will use the more secure thing once they are educated. you know the kind of stuff where you tell the people you support that they will not get tech support any more if they do this. - the argument about 'having to agree on something' is not as bad as it sound because they do it every day on facebook. The one thing I do mind that even I always have to search aruond to find the place where my apps are located. Nicole ~~~ -- Jetzt im Buchhandel: Twitter - Mit 140 Zeichen zum Web 2.0 Amazon: http://tinyurl.com/6at9c5 http://mit140zeichen.de - http://twitter.com/m140z Kontakt: http://twitter.com/NicoleSimon https://www.xing.com/profile/Nicole_Simon skype: nicole.simon / mailto:nicole.si...@mit140zeichen.de phone: +49 451 899 75 03 / mobile: +49 179 499 7076
[twitter-dev] Re: OAUTH: Basic Auth is simpler/more reliable/more secure/better received than OAuth!?
About the first point, this will just keep happening. The only difference is that instead of have their credential stolen, they will have their token stolen. Then, spammers, for example, will use this tokens to send a lot of spam messages, or do whatever they want. When the user notice it will be too late.The damage will be done. Spammers can just provide a simple site, like those test sites around, for example, and collect a lot of request token before send the spams. But it is ok, the user can just block this application without changing the password. That is very nice. Second, there will be applications asking for username and password even if twitter do not support basic authentication anymore. And we can try to educate our users, but, as far as I know all Banks are trying to do this for some couple of years without success. The main problem here is that the security breach of all systems is the user. And unfortunately we can not change them as fast as we can change our codes. :-( That is just my opinion and i´m a little out of date within oauth. I like the idea but think that the current flow is very poor for mobile and embedded devices. regards, Otávio Ribeiro On Fri, Jul 31, 2009 at 9:18 AM, Duane Roelands duane.roela...@gmail.comwrote: With basic auth you are aware of the fact you are giving application credentials, so are able to make thoughtful decision. This is not supported by the evidence, as thousands of people thoughtfully gave their Twitter credentials to TwitViewer and got their accounts stolen. With OAuth you (ordinary user) are not aware of the fact that you give application credentials This is incorrect. WIth OAuth, you don't give your credentials to anyone except Twitter. It's a bad idea to give your account credentials to a third party. Basic Auth forces you to give your account credentials to a third party. Therefore, using Basic Auth is a bad idea. On Jul 31, 8:09 am, Nicole Simon nee...@gmail.com wrote: I am surprised nobody is bringing up these too points: - people will use the more secure thing once they are educated. you know the kind of stuff where you tell the people you support that they will not get tech support any more if they do this. - the argument about 'having to agree on something' is not as bad as it sound because they do it every day on facebook. The one thing I do mind that even I always have to search aruond to find the place where my apps are located. Nicole ~~~ -- Jetzt im Buchhandel: Twitter - Mit 140 Zeichen zum Web 2.0 Amazon:http://tinyurl.com/6at9c5 http://mit140zeichen.de-http://twitter.com/m140z Kontakt: http://twitter.com/NicoleSimonhttps://www.xing.com/profile/Nicole_Simon skype: nicole.simon / mailto:nicole.si...@mit140zeichen.de phone: +49 451 899 75 03 / mobile: +49 179 499 7076
[twitter-dev] Re: OAUTH: Basic Auth is simpler/more reliable/more secure/better received than OAuth!?
No, Sign in with Twitter doesn't have the same flow as Facebook Connect. With Facebook Connect, once your sessions are created, they remain for that user for a given time. The user doesn't have to go through the entire login process again each time you request a signature for them. With Twitter, the user has to go to an *entirely* different page, log in if they haven't, click accept or decline, and then come all the way back to your site, *every time*. I also don't get why you think Facebook Connect is difficult to debug. Sounds like more an issue of education than not. I've had worse issues with OAuth debugging, to tell you the truth. All the methods are provided for you in Facebook Connect to know exactly what's going on - it's actually very simple compared to the work I've done with OAuth, and the user never has to leave my site to login. With OAuth, there's no way of verifying if your URL was written correctly, or what the issue was when tokens weren't returned. With Facebook, all that work is done for you, no coding necessary on your end until the user is authenticated. It's incredibly simple. Jesse On Fri, Jul 31, 2009 at 2:21 AM, Abraham Williams 4bra...@gmail.com wrote: Personally I've found JavaScript based auth systems like Facebook Connect and Google Friend Connect to be very difficult to debug and use. I am also a lot more comfortable with PHP then JS. As far as UX. Sign in with Twitter has the same flow as FBC and GFC. Click a link on your site, jump to provider to authorize, and return to consumer. Abraham On Thu, Jul 30, 2009 at 22:12, Jesse Stay jesses...@gmail.com wrote: I understand the reasoning behind OAuth, and think it's a step in the right direction, but, does Twitter have plans to improve and move to a better Auth system than OAuth? With Facebook Connect I just have to click once, and if the user is already logged in and approved my app, they never see the Facebook login box again. Where as with Twitter there are 3 points of potential failure every single time the user logs in. It's a Ux nightmare, IMO. While it does solve a problem, I don't think OAuth is the end or ideal solution. Are there plans to improve this process? Jesse On Wed, Jul 29, 2009 at 1:05 PM, Doug Williams d...@twitter.com wrote: Well said, Duane. Thanks, Doug On Wed, Jul 29, 2009 at 7:18 AM, Duane Roelands duane.roela...@gmail.com wrote: First, let me state from the start that I am no fan of OAuth, Twitter's implementation of it, or the way that they've behaved with regard to it. Now, with all that being said. If your website expects me to hand over my Twitter password, I'm not using your web site. Just yesterday, another scam site (TwitViewer) managed to steal thousands of accounts, and convince other people to hand over their information because it was posting tweets from the stolen accounts. OAuth is not perfect, but it provides individual users and Twitter with a way to identify bad actors and lock them out of the ecosystem. OAuth works. There are examples out there. There are developers who are willing to help you. Implementing OAuth tells your customers that the security of their account is important to you, and shutting down Basic Auth trains your users to stop giving away their password. If your product has value, and you clearly communicate what that value is, the users will use OAuth. On Jul 29, 9:10 am, Dewald Pretorius dpr...@gmail.com wrote: It would not surprise me at all if using OAuth resulted in fewer signups. Potential technical advantages of OAuth aside, every additional click that you add in the conversion process adds an addition leakage point where some users can and will abandon the signup process. -- Abraham Williams | Community Evangelist | http://web608.org Hacker | http://abrah.am | http://twitter.com/abraham Project | http://fireeagle.labs.poseurtech.com This email is: [ ] blogable [x] ask first [ ] private. Sent from Madison, Wisconsin, United States
[twitter-dev] Re: OAUTH: Basic Auth is simpler/more reliable/more secure/better received than OAuth!?
One security advantage of oauth with desktop apps is allowing the application to keep you logged in without having to store your password in plaintext on the hard disk. This way if the computer is compromised or stolen later on your password is not compromised. I still think the UX with desktop based oauth apps isn't the most joyful and could be improved upon. One possible solution that has been brought up is allowing the desktop app to authorize on your behalf using your username and password. This way the app can get the access token without the user having to visit the SP's site. Once the access token has been retrieved the application can forget the password and remain logged in even if the password changes in the future. All resource requests would then be done using oauth with the access token. Overall I think OAuth is a good solution for API authentication. Its secure and provides benefits to the user, consumer, and sp. On Fri, Jul 31, 2009 at 9:41 AM, Christopher St John ckstj...@gmail.comwrote: On Thu, Jul 30, 2009 at 6:07 PM, Bradley S. O'Hearnebrad.ohea...@gmail.com wrote: I really want to hear stated, or read on a FAQ, is the pre-requisite security trust, that in that scenario, it necessarily makes OAuth superior to basic authentication. The problem here is that you're paying attention, instead of just accepting oauth is better because it is! statements :-) For desktop apps (and in any case where the application has has control of the UI and/or your computer) OAuth has no security advantage (since the app can snoop the interaction) I'm sure bad people are working on a way to make this true in browser apps as well, but I don't know of any examples. For web applications, many commentators acknowledge an increased risk of phishing as a potential problem with OAuth, although I haven't personally read any studies that indicate whether it's a theoretical or practical problem at this point. In any case, the primary benefit in OAuth is not protecting the user immediately from an evil application (since the authorization tokens an OAuth server hand out are just as powerful as passwords and must be protected like passwords) it's that: - the owners of the service can (in theory) administratively ban an application without forcing all the users to change their passwords (a potentially very big benefit, maybe the single benefit that justifies the general inconvenience) - an individual user can ban an application by revoking its authz token without having to change their password (a moderate-at-best benefit, since you could always just change your password) - an individual who is using exactly the same password at many sites doesn't have to expose out their mono-password to an app (people mention this a lot, but come on, should security system try to make people feel better about hitting themselves on the head with a hammer? but this gets mentioned a lot, so there you go) So, the security picture is actually a little fuzzy. There are some big wins for service administrators, some real (but medium-sized?) wins for users, some fundamental limits of applicability (web-apps only) and some open questions about phishing and snooping. And lots and lots of hype :-) -cks -- Christopher St. John http://praxisbridge.com http://artofsystems.blogspot.com -- Josh
[twitter-dev] Re: OAUTH: Basic Auth is simpler/more reliable/more secure/better received than OAuth!?
Jesse, That is not true. With the Sign in with Twitter flow (not the standard OAuth flow which is also available) -- If the user is logged in and has previously approved the app, they will be immediately redirected back to the application without ever seeing a Twitter dialog. Thanks, Doug On Fri, Jul 31, 2009 at 9:31 AM, Jesse Stay jesses...@gmail.com wrote: No, Sign in with Twitter doesn't have the same flow as Facebook Connect. With Facebook Connect, once your sessions are created, they remain for that user for a given time. The user doesn't have to go through the entire login process again each time you request a signature for them. With Twitter, the user has to go to an *entirely* different page, log in if they haven't, click accept or decline, and then come all the way back to your site, *every time*. I also don't get why you think Facebook Connect is difficult to debug. Sounds like more an issue of education than not. I've had worse issues with OAuth debugging, to tell you the truth. All the methods are provided for you in Facebook Connect to know exactly what's going on - it's actually very simple compared to the work I've done with OAuth, and the user never has to leave my site to login. With OAuth, there's no way of verifying if your URL was written correctly, or what the issue was when tokens weren't returned. With Facebook, all that work is done for you, no coding necessary on your end until the user is authenticated. It's incredibly simple. Jesse On Fri, Jul 31, 2009 at 2:21 AM, Abraham Williams 4bra...@gmail.comwrote: Personally I've found JavaScript based auth systems like Facebook Connect and Google Friend Connect to be very difficult to debug and use. I am also a lot more comfortable with PHP then JS. As far as UX. Sign in with Twitter has the same flow as FBC and GFC. Click a link on your site, jump to provider to authorize, and return to consumer. Abraham On Thu, Jul 30, 2009 at 22:12, Jesse Stay jesses...@gmail.com wrote: I understand the reasoning behind OAuth, and think it's a step in the right direction, but, does Twitter have plans to improve and move to a better Auth system than OAuth? With Facebook Connect I just have to click once, and if the user is already logged in and approved my app, they never see the Facebook login box again. Where as with Twitter there are 3 points of potential failure every single time the user logs in. It's a Ux nightmare, IMO. While it does solve a problem, I don't think OAuth is the end or ideal solution. Are there plans to improve this process? Jesse On Wed, Jul 29, 2009 at 1:05 PM, Doug Williams d...@twitter.com wrote: Well said, Duane. Thanks, Doug On Wed, Jul 29, 2009 at 7:18 AM, Duane Roelands duane.roela...@gmail.com wrote: First, let me state from the start that I am no fan of OAuth, Twitter's implementation of it, or the way that they've behaved with regard to it. Now, with all that being said. If your website expects me to hand over my Twitter password, I'm not using your web site. Just yesterday, another scam site (TwitViewer) managed to steal thousands of accounts, and convince other people to hand over their information because it was posting tweets from the stolen accounts. OAuth is not perfect, but it provides individual users and Twitter with a way to identify bad actors and lock them out of the ecosystem. OAuth works. There are examples out there. There are developers who are willing to help you. Implementing OAuth tells your customers that the security of their account is important to you, and shutting down Basic Auth trains your users to stop giving away their password. If your product has value, and you clearly communicate what that value is, the users will use OAuth. On Jul 29, 9:10 am, Dewald Pretorius dpr...@gmail.com wrote: It would not surprise me at all if using OAuth resulted in fewer signups. Potential technical advantages of OAuth aside, every additional click that you add in the conversion process adds an addition leakage point where some users can and will abandon the signup process. -- Abraham Williams | Community Evangelist | http://web608.org Hacker | http://abrah.am | http://twitter.com/abraham Project | http://fireeagle.labs.poseurtech.com This email is: [ ] blogable [x] ask first [ ] private. Sent from Madison, Wisconsin, United States
[twitter-dev] Re: OAUTH: Basic Auth is simpler/more reliable/more secure/better received than OAuth!?
Doug, interesting - I didn't realize that's what Sign on With Twitter did. Last I tried that wasn't working though - is that working now? Jesse On Fri, Jul 31, 2009 at 1:31 PM, Doug Williams d...@twitter.com wrote: Jesse, That is not true. With the Sign in with Twitter flow (not the standard OAuth flow which is also available) -- If the user is logged in and has previously approved the app, they will be immediately redirected back to the application without ever seeing a Twitter dialog. Thanks, Doug On Fri, Jul 31, 2009 at 9:31 AM, Jesse Stay jesses...@gmail.com wrote: No, Sign in with Twitter doesn't have the same flow as Facebook Connect. With Facebook Connect, once your sessions are created, they remain for that user for a given time. The user doesn't have to go through the entire login process again each time you request a signature for them. With Twitter, the user has to go to an *entirely* different page, log in if they haven't, click accept or decline, and then come all the way back to your site, *every time*. I also don't get why you think Facebook Connect is difficult to debug. Sounds like more an issue of education than not. I've had worse issues with OAuth debugging, to tell you the truth. All the methods are provided for you in Facebook Connect to know exactly what's going on - it's actually very simple compared to the work I've done with OAuth, and the user never has to leave my site to login. With OAuth, there's no way of verifying if your URL was written correctly, or what the issue was when tokens weren't returned. With Facebook, all that work is done for you, no coding necessary on your end until the user is authenticated. It's incredibly simple. Jesse On Fri, Jul 31, 2009 at 2:21 AM, Abraham Williams 4bra...@gmail.comwrote: Personally I've found JavaScript based auth systems like Facebook Connect and Google Friend Connect to be very difficult to debug and use. I am also a lot more comfortable with PHP then JS. As far as UX. Sign in with Twitter has the same flow as FBC and GFC. Click a link on your site, jump to provider to authorize, and return to consumer. Abraham On Thu, Jul 30, 2009 at 22:12, Jesse Stay jesses...@gmail.com wrote: I understand the reasoning behind OAuth, and think it's a step in the right direction, but, does Twitter have plans to improve and move to a better Auth system than OAuth? With Facebook Connect I just have to click once, and if the user is already logged in and approved my app, they never see the Facebook login box again. Where as with Twitter there are 3 points of potential failure every single time the user logs in. It's a Ux nightmare, IMO. While it does solve a problem, I don't think OAuth is the end or ideal solution. Are there plans to improve this process? Jesse On Wed, Jul 29, 2009 at 1:05 PM, Doug Williams d...@twitter.comwrote: Well said, Duane. Thanks, Doug On Wed, Jul 29, 2009 at 7:18 AM, Duane Roelands duane.roela...@gmail.com wrote: First, let me state from the start that I am no fan of OAuth, Twitter's implementation of it, or the way that they've behaved with regard to it. Now, with all that being said. If your website expects me to hand over my Twitter password, I'm not using your web site. Just yesterday, another scam site (TwitViewer) managed to steal thousands of accounts, and convince other people to hand over their information because it was posting tweets from the stolen accounts. OAuth is not perfect, but it provides individual users and Twitter with a way to identify bad actors and lock them out of the ecosystem. OAuth works. There are examples out there. There are developers who are willing to help you. Implementing OAuth tells your customers that the security of their account is important to you, and shutting down Basic Auth trains your users to stop giving away their password. If your product has value, and you clearly communicate what that value is, the users will use OAuth. On Jul 29, 9:10 am, Dewald Pretorius dpr...@gmail.com wrote: It would not surprise me at all if using OAuth resulted in fewer signups. Potential technical advantages of OAuth aside, every additional click that you add in the conversion process adds an addition leakage point where some users can and will abandon the signup process. -- Abraham Williams | Community Evangelist | http://web608.org Hacker | http://abrah.am | http://twitter.com/abraham Project | http://fireeagle.labs.poseurtech.com This email is: [ ] blogable [x] ask first [ ] private. Sent from Madison, Wisconsin, United States
[twitter-dev] Re: OAUTH: Basic Auth is simpler/more reliable/more secure/better received than OAuth!?
Jesse, If it is not, then it is a defect. That is the intended functionality. Thanks, Doug On Fri, Jul 31, 2009 at 10:57 AM, Jesse Stay jesses...@gmail.com wrote: Doug, interesting - I didn't realize that's what Sign on With Twitter did. Last I tried that wasn't working though - is that working now? Jesse On Fri, Jul 31, 2009 at 1:31 PM, Doug Williams d...@twitter.com wrote: Jesse, That is not true. With the Sign in with Twitter flow (not the standard OAuth flow which is also available) -- If the user is logged in and has previously approved the app, they will be immediately redirected back to the application without ever seeing a Twitter dialog. Thanks, Doug On Fri, Jul 31, 2009 at 9:31 AM, Jesse Stay jesses...@gmail.com wrote: No, Sign in with Twitter doesn't have the same flow as Facebook Connect. With Facebook Connect, once your sessions are created, they remain for that user for a given time. The user doesn't have to go through the entire login process again each time you request a signature for them. With Twitter, the user has to go to an *entirely* different page, log in if they haven't, click accept or decline, and then come all the way back to your site, *every time*. I also don't get why you think Facebook Connect is difficult to debug. Sounds like more an issue of education than not. I've had worse issues with OAuth debugging, to tell you the truth. All the methods are provided for you in Facebook Connect to know exactly what's going on - it's actually very simple compared to the work I've done with OAuth, and the user never has to leave my site to login. With OAuth, there's no way of verifying if your URL was written correctly, or what the issue was when tokens weren't returned. With Facebook, all that work is done for you, no coding necessary on your end until the user is authenticated. It's incredibly simple. Jesse On Fri, Jul 31, 2009 at 2:21 AM, Abraham Williams 4bra...@gmail.comwrote: Personally I've found JavaScript based auth systems like Facebook Connect and Google Friend Connect to be very difficult to debug and use. I am also a lot more comfortable with PHP then JS. As far as UX. Sign in with Twitter has the same flow as FBC and GFC. Click a link on your site, jump to provider to authorize, and return to consumer. Abraham On Thu, Jul 30, 2009 at 22:12, Jesse Stay jesses...@gmail.com wrote: I understand the reasoning behind OAuth, and think it's a step in the right direction, but, does Twitter have plans to improve and move to a better Auth system than OAuth? With Facebook Connect I just have to click once, and if the user is already logged in and approved my app, they never see the Facebook login box again. Where as with Twitter there are 3 points of potential failure every single time the user logs in. It's a Ux nightmare, IMO. While it does solve a problem, I don't think OAuth is the end or ideal solution. Are there plans to improve this process? Jesse On Wed, Jul 29, 2009 at 1:05 PM, Doug Williams d...@twitter.comwrote: Well said, Duane. Thanks, Doug On Wed, Jul 29, 2009 at 7:18 AM, Duane Roelands duane.roela...@gmail.com wrote: First, let me state from the start that I am no fan of OAuth, Twitter's implementation of it, or the way that they've behaved with regard to it. Now, with all that being said. If your website expects me to hand over my Twitter password, I'm not using your web site. Just yesterday, another scam site (TwitViewer) managed to steal thousands of accounts, and convince other people to hand over their information because it was posting tweets from the stolen accounts. OAuth is not perfect, but it provides individual users and Twitter with a way to identify bad actors and lock them out of the ecosystem. OAuth works. There are examples out there. There are developers who are willing to help you. Implementing OAuth tells your customers that the security of their account is important to you, and shutting down Basic Auth trains your users to stop giving away their password. If your product has value, and you clearly communicate what that value is, the users will use OAuth. On Jul 29, 9:10 am, Dewald Pretorius dpr...@gmail.com wrote: It would not surprise me at all if using OAuth resulted in fewer signups. Potential technical advantages of OAuth aside, every additional click that you add in the conversion process adds an addition leakage point where some users can and will abandon the signup process. -- Abraham Williams | Community Evangelist | http://web608.org Hacker | http://abrah.am | http://twitter.com/abraham Project | http://fireeagle.labs.poseurtech.com This email is: [ ] blogable [x] ask first [ ] private. Sent from Madison, Wisconsin, United States
[twitter-dev] Re: OAUTH: Basic Auth is simpler/more reliable/more secure/better received than OAuth!?
Christopher, It is good to see that someone understands the bigger picture here. This conversation suffers from a presumption of a specific use-case (web application communicating with Twitter), and a particular presumption of trust, or lack thereof. The particular comments such as: You can lead a horse to water ... and This is not rocket science. pretty much demonstrate a very narrow contextual view, in which their view might make sense, but outside of which it does not. Restated, this is optimistic thinking from the perspective of their particular use case, and ignores the perspective of either other use cases, and overlooks someone trying to exploit a security vulnerability. To my knowledge, and certainly in this conversation, OAuth is being touted as an across-the-board superior security approach for ALL use cases. Having spent the better part of the last two and half years doing secure data storage development far more complex than that of just authorization, but also securing the payloads across an entire cloud and desktops, and the network as a whole, my comments here are simply to see the claim of OAuth being undisputably superior supported with fact against legitimate breach points. I'll give an example. My personal development use case for security is communicating with Twitter from an iPhone app. Applying the same broad brush you wouldn't give your data to a complete stranger comments to the iPhone, your complete stranger here is the iPhone app you are using. So effectively, your complete stranger assertion maps to the following: 1) You've downloaded an app from the App Store with the intention of using it for communicating with Twitter, yet it is considered a complete stranger, and untrusted. 2) You use the app, and explicitly initiate communication to Twitter within this very complete stranger. This complete stranger assertion is absurd. First, you haven't treated the iPhone app like a complete stranger. You explicitly downloaded (and likely paid money) to explicitly put this application on your phone. Furthermore, it doesn't really matter if you pull up the OAuth login page within your iPhone app. That complete stranger iPhone app could capture keyboard events and/or filter EVERYTHING you send across the wire prior to any encryption being applied. Furthermore, even if OAuth itself isn't breached, as soon as your token is acquired, what's to prevent the app from then going absolutely haywire with your account, posting malicious status, following / blocking who it chooses, etc.? Furthermore, all of the other apps comments don't directly apply -- every app on the iPhone is sandboxed, which protects it from any other app tampering or accessing data. The only breach of this, of course, is jailbreaking, but then again this is analogous to someone hacking and owning the desktop you are browsing on, in which case OAuth is no protection again. The variance for desktop apps is that they aren't sandboxed away from other apps on the machine, but other than that, most of this all applies to that environment too. Unless other information surfaces, Christopher, best I can tell, you are spot on. OAuth seems particularly relevant to web applications, and relevant to desktop and iPhone apps primarily if your desktop / iPhone are NOT password protected, and the application in question has stored credentials, and you either lose or have stolen your desktop / iPhone. In conclusion, addressing one last example of ATM cards and pins -- you picked the safe example. A credit card is far less safe than all of this, because lose one of those, and the finder is on a shopping spree, no ID or pin required. And I'd bet 99% of this mailing list, including the OAuth devotees, carry a credit card, and don't think twice about the fact that they are one hole in their pocket away from receiving a truckload of Shamwow's delivered to their house. Regards, Brad On Jul 31, 2009, at 7:41 AM, Christopher St John wrote: On Thu, Jul 30, 2009 at 6:07 PM, Bradley S. O'Hearnebrad.ohea...@gmail.com wrote: I really want to hear stated, or read on a FAQ, is the pre-requisite security trust, that in that scenario, it necessarily makes OAuth superior to basic authentication. The problem here is that you're paying attention, instead of just accepting oauth is better because it is! statements :-) For desktop apps (and in any case where the application has has control of the UI and/or your computer) OAuth has no security advantage (since the app can snoop the interaction) I'm sure bad people are working on a way to make this true in browser apps as well, but I don't know of any examples. For web applications, many commentators acknowledge an increased risk of phishing as a potential problem with OAuth, although I haven't personally read any studies that indicate whether it's a theoretical or practical
[twitter-dev] Re: OAUTH: Basic Auth is simpler/more reliable/more secure/better received than OAuth!?
On Fri, Jul 31, 2009 at 21:02, Bradley S. O'Hearne brad.ohea...@gmail.comwrote: In conclusion, addressing one last example of ATM cards and pins -- you picked the safe example. A credit card is far less safe than all of this, because lose one of those, and the finder is on a shopping spree, no ID or pin required. And I'd bet 99% of this mailing list, including the OAuth devotees, carry a credit card, and don't think twice about the fact that they are one hole in their pocket away from receiving a truckload of Shamwow's delivered to their house. My God, you're RIGHT. I could have a hole in my pocket, lose my credit card, and NEVER BE ABLE TO BUY THE TRUCKLOAD OF SHAMWOWS I SO RICHLY DESIRE. I assume that's what you meant, anyway ;) -- Internets. Serious business.
[twitter-dev] Re: OAUTH: Basic Auth is simpler/more reliable/more secure/better received than OAuth!?
On Jul 28, 3:27 pm, chinaski007 chinaski...@gmail.com wrote: I suppose this is not so weird. Users are accustomed to giving user/ pass information even to foreign apps. Agree. Anyway, if user just setups desktop app to his computer, he already gives it much more than just login/password to some service. And then there is 1000 and 1 way how app can then get all needed info passing over user. -- Dmitriy V'jukov
[twitter-dev] Re: OAUTH: Basic Auth is simpler/more reliable/more secure/better received than OAuth!?
All, Just a question along the same lines as Dmitriy's, and forwarding no opinion one way or the other -- but I'm curious, as security discussions often end up being debates about one particular facet of a security scheme while not considering the big picture. What is the breach that OAuth is primarily concerned with here? Granted that in principle one doesn't want to be throwing passwords around, but I see two concerns: 1. Passwords being intercepted as sent across the wire. Comment: If credentials have to be passed over the wire to authenticate a session, doesn't HTTPS really alleviate this concern? In order to breach HTTPS you'd have to either crack the encryption, or spoof the Twitter endpoint and support it by somehow spoofing the certificate authority chain. And if someone could do this, then OAuth is no safeguard, because they could do the same with whatever app or session token is the key to the city. 2. Passwords being stored locally. Comment: The application integrating with Twitter is already effectively trusted, so the concern should not be with the app itself. The concern here would be other apps or people being able to grab passwords off of disk where stored. Again, I think this goes back to encryption. If all credentials are encrypted locally, then again, the concern becomes the breaking of encryption, and if that is done, then again whatever app or session token represents the key to the city can be acquired to use in OAuth too, if I'm not mistaken. Now admittedly, I haven't gone through OAuth with a fine-toothed comb, but I have read the docs and examined the process. If I'm not mistaken, OAuth doesn't alleviate authentication, it just puts the actual username and password out of the regular communication and need to be stored locally, but replaces it with an alternative token, which does need to be stored locally, and passed across the wire. That token now becomes the key to the city, no? In conclusion, as I've been reading this thread, the thing I keep coming back to is that OAuth vs. Basic Auth seems somewhat a secondary argument -- the real issue is encrypting over the wire (HTTPS) and encryption on disk, and whether those can be cracked (or are being used as they should). From a developer standpoint, given that the cracking of encryption seems outside the scope of concerns with the Twitter API, what is analog is which one serves the user better -- and I think it is clear that the Basic Auth case has fewer steps and quicker to the result. Please correct my misperceptions if I'm wrong, as I'd love to hear what details I've overlooked. Regards, Brad On Jul 30, 2009, at 1:29 AM, Dmitriy V'jukov wrote: On Jul 28, 3:27 pm, chinaski007 chinaski...@gmail.com wrote: I suppose this is not so weird. Users are accustomed to giving user/ pass information even to foreign apps. Agree. Anyway, if user just setups desktop app to his computer, he already gives it much more than just login/password to some service. And then there is 1000 and 1 way how app can then get all needed info passing over user. -- Dmitriy V'jukov
[twitter-dev] Re: OAUTH: Basic Auth is simpler/more reliable/more secure/better received than OAuth!?
Duane, I understand the concern. But I think the conversation is moving closer to the actual issue. Your example of turning Twitter credentials to a stranger basically makes the application (or computer) that the user has already willfully chosen to use a complete stranger. I would debate that is necessarily the case, but let's for the moment assume it is the case, and see the problem with that assumption. In that case, OAuth *still* requires production of credentials to a complete stranger. Because it supposedly redirects to the Twitter web site for authentication doesn't save you from the either originating web site, the browser, or the machine itself spoofing the redirect -- I mean you've already labeled them a complete stranger, so you have to allow now for that possibility. Additionally, that login directly into Twitter also doesn't save you from keyboard logging or phishing on the machine -- or, and I'm not 100% sure on this one but I think it is possible, malicious browser plugins. So here we get into the issue of not just a single trusted / non-trusted app, but whether it is a trusted box or not. Perhaps I'm still ignorant, but unless I've completely missed the boat, credentials are still being produced -- i mean, at some point they have to be, otherwise they wouldn't be credentials, something else would be. I think what I'm really responding to here is the lack of context given to discussions surrounding OAuth's security -- there are blanket statements being made about not giving a stranger passwords, and OAuth somehow solving that. Well, that stranger happens to be the machine you've chosen to trust. Just because OAuth exists, it doesn't make Twittering or accessing Twitter data from Facebook on an Internet Cafe computer any safer necessarily. There is a degree of trust somewhere that is being trusted as a beginning prerequisite. I do not believe there is a no-trust scenario here. What I really want to hear stated, or read on a FAQ, is the pre-requisite security trust, that in that scenario, it necessarily makes OAuth superior to basic authentication. Brad On Jul 30, 2009, at 11:52 AM, Duane Roelands wrote: Brad, Encryption on disk and encryption over the wire are not the issues and really don't have very much to do with the Basic vs. OAuth decision. The most important issue I see is that Basic Auth requires you to give your Twitter credentials to a person you do not know. This is a BAD IDEA. Basic Auth is great for prototyping and testing and getting the core functionality of your app working, but at some point you should bit the bullet and implement OAuth. It's better for your customers (security) and it's better for you because your customers can use your application with peace of mind. If YOU wouldn't hand over YOUR Twitter credentials to a stranger, it's silly to expect your users to do so. On Jul 30, 11:40 am, Bradley S. O'Hearne brad.ohea...@gmail.com wrote: In conclusion, as I've been reading this thread, the thing I keep coming back to is that OAuth vs. Basic Auth seems somewhat a secondary argument -- the real issue is encrypting over the wire (HTTPS) and encryption on disk, and whether those can be cracked (or are being used as they should). From a developer standpoint, given that the cracking of encryption seems outside the scope of concerns with the Twitter API, what is analog is which one serves the user better -- and I think it is clear that the Basic Auth case has fewer steps and quicker to the result. Please correct my misperceptions if I'm wrong, as I'd love to hear what details I've overlooked. Regards, Brad On Jul 30, 2009, at 1:29 AM, Dmitriy V'jukov wrote: On Jul 28, 3:27 pm, chinaski007 chinaski...@gmail.com wrote: I suppose this is not so weird. Users are accustomed to giving user/ pass information even to foreign apps. Agree. Anyway, if user just setups desktop app to his computer, he already gives it much more than just login/password to some service. And then there is 1000 and 1 way how app can then get all needed info passing over user. -- Dmitriy V'jukov
[twitter-dev] Re: OAUTH: Basic Auth is simpler/more reliable/more secure/better received than OAuth!?
You can lead a horse to water ... On Thu, Jul 30, 2009 at 7:07 PM, Bradley S. O'Hearne brad.ohea...@gmail.com wrote: Duane, I understand the concern. But I think the conversation is moving closer to the actual issue. Your example of turning Twitter credentials to a stranger basically makes the application (or computer) that the user has already willfully chosen to use a complete stranger. I would debate that is necessarily the case, but let's for the moment assume it is the case, and see the problem with that assumption. In that case, OAuth *still* requires production of credentials to a complete stranger. Because it supposedly redirects to the Twitter web site for authentication doesn't save you from the either originating web site, the browser, or the machine itself spoofing the redirect -- I mean you've already labeled them a complete stranger, so you have to allow now for that possibility. Additionally, that login directly into Twitter also doesn't save you from keyboard logging or phishing on the machine -- or, and I'm not 100% sure on this one but I think it is possible, malicious browser plugins. So here we get into the issue of not just a single trusted / non-trusted app, but whether it is a trusted box or not. Perhaps I'm still ignorant, but unless I've completely missed the boat, credentials are still being produced -- i mean, at some point they have to be, otherwise they wouldn't be credentials, something else would be. I think what I'm really responding to here is the lack of context given to discussions surrounding OAuth's security -- there are blanket statements being made about not giving a stranger passwords, and OAuth somehow solving that. Well, that stranger happens to be the machine you've chosen to trust. Just because OAuth exists, it doesn't make Twittering or accessing Twitter data from Facebook on an Internet Cafe computer any safer necessarily. There is a degree of trust somewhere that is being trusted as a beginning prerequisite. I do not believe there is a no-trust scenario here. What I really want to hear stated, or read on a FAQ, is the pre-requisite security trust, that in that scenario, it necessarily makes OAuth superior to basic authentication. Brad On Jul 30, 2009, at 11:52 AM, Duane Roelands wrote: Brad, Encryption on disk and encryption over the wire are not the issues and really don't have very much to do with the Basic vs. OAuth decision. The most important issue I see is that Basic Auth requires you to give your Twitter credentials to a person you do not know. This is a BAD IDEA. Basic Auth is great for prototyping and testing and getting the core functionality of your app working, but at some point you should bit the bullet and implement OAuth. It's better for your customers (security) and it's better for you because your customers can use your application with peace of mind. If YOU wouldn't hand over YOUR Twitter credentials to a stranger, it's silly to expect your users to do so. On Jul 30, 11:40 am, Bradley S. O'Hearne brad.ohea...@gmail.com wrote: In conclusion, as I've been reading this thread, the thing I keep coming back to is that OAuth vs. Basic Auth seems somewhat a secondary argument -- the real issue is encrypting over the wire (HTTPS) and encryption on disk, and whether those can be cracked (or are being used as they should). From a developer standpoint, given that the cracking of encryption seems outside the scope of concerns with the Twitter API, what is analog is which one serves the user better -- and I think it is clear that the Basic Auth case has fewer steps and quicker to the result. Please correct my misperceptions if I'm wrong, as I'd love to hear what details I've overlooked. Regards, Brad On Jul 30, 2009, at 1:29 AM, Dmitriy V'jukov wrote: On Jul 28, 3:27 pm, chinaski007 chinaski...@gmail.com wrote: I suppose this is not so weird. Users are accustomed to giving user/ pass information even to foreign apps. Agree. Anyway, if user just setups desktop app to his computer, he already gives it much more than just login/password to some service. And then there is 1000 and 1 way how app can then get all needed info passing over user. -- Dmitriy V'jukov
[twitter-dev] Re: OAUTH: Basic Auth is simpler/more reliable/more secure/better received than OAuth!?
OAuth lets you access the Twitter service without giving your Twitter credentials to anyone but Twitter. Basic Auth requires you to give your Twitter credentials to someone other than Twitter. Therefore, OAuth is more secure than Basic Auth. This is not rocket science. On Jul 30, 7:07 pm, Bradley S. O'Hearne brad.ohea...@gmail.com wrote: In that case, OAuth *still* requires production of credentials to a complete stranger. Because it supposedly redirects to the Twitter web site for authentication doesn't save you from the either originating web site, the browser, or the machine itself spoofing the redirect -- I mean you've already labeled them a complete stranger, so you have to allow now for that possibility. Additionally, that login directly into Twitter also doesn't save you from keyboard logging or phishing on the machine -- or, and I'm not 100% sure on this one but I think it is possible, malicious browser plugins. So here we get into the issue of not just a single trusted / non-trusted app, but whether it is a trusted box or not. Perhaps I'm still ignorant, but unless I've completely missed the boat, credentials are still being produced -- i mean, at some point they have to be, otherwise they wouldn't be credentials, something else would be. I think what I'm really responding to here is the lack of context given to discussions surrounding OAuth's security -- there are blanket statements being made about not giving a stranger passwords, and OAuth somehow solving that. Well, that stranger happens to be the machine you've chosen to trust. Just because OAuth exists, it doesn't make Twittering or accessing Twitter data from Facebook on an Internet Cafe computer any safer necessarily. There is a degree of trust somewhere that is being trusted as a beginning prerequisite. I do not believe there is a no-trust scenario here. What I really want to hear stated, or read on a FAQ, is the pre-requisite security trust, that in that scenario, it necessarily makes OAuth superior to basic authentication. Brad On Jul 30, 2009, at 11:52 AM, Duane Roelands wrote: Brad, Encryption on disk and encryption over the wire are not the issues and really don't have very much to do with the Basic vs. OAuth decision. The most important issue I see is that Basic Auth requires you to give your Twitter credentials to a person you do not know. This is a BAD IDEA. Basic Auth is great for prototyping and testing and getting the core functionality of your app working, but at some point you should bit the bullet and implement OAuth. It's better for your customers (security) and it's better for you because your customers can use your application with peace of mind. If YOU wouldn't hand over YOUR Twitter credentials to a stranger, it's silly to expect your users to do so. On Jul 30, 11:40 am, Bradley S. O'Hearne brad.ohea...@gmail.com wrote: In conclusion, as I've been reading this thread, the thing I keep coming back to is that OAuth vs. Basic Auth seems somewhat a secondary argument -- the real issue is encrypting over the wire (HTTPS) and encryption on disk, and whether those can be cracked (or are being used as they should). From a developer standpoint, given that the cracking of encryption seems outside the scope of concerns with the Twitter API, what is analog is which one serves the user better -- and I think it is clear that the Basic Auth case has fewer steps and quicker to the result. Please correct my misperceptions if I'm wrong, as I'd love to hear what details I've overlooked. Regards, Brad On Jul 30, 2009, at 1:29 AM, Dmitriy V'jukov wrote: On Jul 28, 3:27 pm, chinaski007 chinaski...@gmail.com wrote: I suppose this is not so weird. Users are accustomed to giving user/ pass information even to foreign apps. Agree. Anyway, if user just setups desktop app to his computer, he already gives it much more than just login/password to some service. And then there is 1000 and 1 way how app can then get all needed info passing over user. -- Dmitriy V'jukov
[twitter-dev] Re: OAUTH: Basic Auth is simpler/more reliable/more secure/better received than OAuth!?
I understand the reasoning behind OAuth, and think it's a step in the right direction, but, does Twitter have plans to improve and move to a better Auth system than OAuth? With Facebook Connect I just have to click once, and if the user is already logged in and approved my app, they never see the Facebook login box again. Where as with Twitter there are 3 points of potential failure every single time the user logs in. It's a Ux nightmare, IMO. While it does solve a problem, I don't think OAuth is the end or ideal solution. Are there plans to improve this process? Jesse On Wed, Jul 29, 2009 at 1:05 PM, Doug Williams d...@twitter.com wrote: Well said, Duane. Thanks, Doug On Wed, Jul 29, 2009 at 7:18 AM, Duane Roelands duane.roela...@gmail.comwrote: First, let me state from the start that I am no fan of OAuth, Twitter's implementation of it, or the way that they've behaved with regard to it. Now, with all that being said. If your website expects me to hand over my Twitter password, I'm not using your web site. Just yesterday, another scam site (TwitViewer) managed to steal thousands of accounts, and convince other people to hand over their information because it was posting tweets from the stolen accounts. OAuth is not perfect, but it provides individual users and Twitter with a way to identify bad actors and lock them out of the ecosystem. OAuth works. There are examples out there. There are developers who are willing to help you. Implementing OAuth tells your customers that the security of their account is important to you, and shutting down Basic Auth trains your users to stop giving away their password. If your product has value, and you clearly communicate what that value is, the users will use OAuth. On Jul 29, 9:10 am, Dewald Pretorius dpr...@gmail.com wrote: It would not surprise me at all if using OAuth resulted in fewer signups. Potential technical advantages of OAuth aside, every additional click that you add in the conversion process adds an addition leakage point where some users can and will abandon the signup process.
[twitter-dev] Re: OAUTH: Basic Auth is simpler/more reliable/more secure/better received than OAuth!?
It would not surprise me at all if using OAuth resulted in fewer signups. Potential technical advantages of OAuth aside, every additional click that you add in the conversion process adds an addition leakage point where some users can and will abandon the signup process.
[twitter-dev] Re: OAUTH: Basic Auth is simpler/more reliable/more secure/better received than OAuth!?
First, let me state from the start that I am no fan of OAuth, Twitter's implementation of it, or the way that they've behaved with regard to it. Now, with all that being said. If your website expects me to hand over my Twitter password, I'm not using your web site. Just yesterday, another scam site (TwitViewer) managed to steal thousands of accounts, and convince other people to hand over their information because it was posting tweets from the stolen accounts. OAuth is not perfect, but it provides individual users and Twitter with a way to identify bad actors and lock them out of the ecosystem. OAuth works. There are examples out there. There are developers who are willing to help you. Implementing OAuth tells your customers that the security of their account is important to you, and shutting down Basic Auth trains your users to stop giving away their password. If your product has value, and you clearly communicate what that value is, the users will use OAuth. On Jul 29, 9:10 am, Dewald Pretorius dpr...@gmail.com wrote: It would not surprise me at all if using OAuth resulted in fewer signups. Potential technical advantages of OAuth aside, every additional click that you add in the conversion process adds an addition leakage point where some users can and will abandon the signup process.
[twitter-dev] Re: OAUTH: Basic Auth is simpler/more reliable/more secure/better received than OAuth!?
Well said, Duane. Thanks, Doug On Wed, Jul 29, 2009 at 7:18 AM, Duane Roelands duane.roela...@gmail.comwrote: First, let me state from the start that I am no fan of OAuth, Twitter's implementation of it, or the way that they've behaved with regard to it. Now, with all that being said. If your website expects me to hand over my Twitter password, I'm not using your web site. Just yesterday, another scam site (TwitViewer) managed to steal thousands of accounts, and convince other people to hand over their information because it was posting tweets from the stolen accounts. OAuth is not perfect, but it provides individual users and Twitter with a way to identify bad actors and lock them out of the ecosystem. OAuth works. There are examples out there. There are developers who are willing to help you. Implementing OAuth tells your customers that the security of their account is important to you, and shutting down Basic Auth trains your users to stop giving away their password. If your product has value, and you clearly communicate what that value is, the users will use OAuth. On Jul 29, 9:10 am, Dewald Pretorius dpr...@gmail.com wrote: It would not surprise me at all if using OAuth resulted in fewer signups. Potential technical advantages of OAuth aside, every additional click that you add in the conversion process adds an addition leakage point where some users can and will abandon the signup process.
[twitter-dev] Re: OAUTH: Basic Auth is simpler/more reliable/more secure/better received than OAuth!?
On Jul 28, 4:16 pm, Isaiah supp...@yourhead.com wrote: I publish an open source example of using a OAuth in a standalone mac app -- so I'm bought in to the OAuth idea. But it wasn't easy, I had to fight to make it appear even somewhat integrated, and the lack of security around my apps private keys really freaks me out. On the other hand I see a lot of posts like this where I tilt my head and say, what are you talking about? Because I just don't get where you're coming from. It's like there's some hidden assumption someone forgot to tell me. So, please don't take offense, I'd just like to play devil's advocate and ask you to back up these reasons with some more info. I'll try to be specific about what seems odd, or at least odd to me: I really loved OAuth because: (1) Ease of coding. I could get OAuth working within a couple of days. You're saying that OAuth was easier to implement than basic auth? How so? Basic auth just places the authorization info into the request -- oauth requires the entire token request, token exchange, token inclusion dance. At best I could see someone arguing that it's roughly the same because you can use a nice library either way, but saying OAuth is actually easier seems a bit far fetched. I was merely advocating about OAuth here. I didn't play around with BasicAuth since OAuth was available when I started developing twaller.com. I wanted to respond to comments which said, OAuth is hard to code etc., by saying I didn't feel that way, mainly because I used the library Twitter4J. Saves me any password maintenance, encryption etc. But how do you maintain the user's auth tokens? Since they're basically as powerful as a password (so long as the user has not turned them off) they need to be given the same care, right? In my implementation I save them just like passwords. Are other developers not doing this? If not why not? I think there is a difference. I find passwords messy because if someone wants to misuse them, they can potentially misuse them for other websites beyond twitter. Many people including myself have similar usernames and exactly the same password in multiple websites. So if I accidently leak a password, and someone uses that to login a bank website and make a financial transaction, that will not look very good. Oauth token's are limited to Twitter use. At the moment, i am not encrypting it in my database. (2) Integration with Twitter Branding. With the OAuth scheme, I believe my website is more integrated with Twitter. It would also be nicer if Twitter would maintain their own list of websites they trust with Oauth, just to give users the added confidence that Twitter trusts me. I'm sure if Twitter decided that tomorrow that OAuth was out, and that PAuth or QAuth were the new black, then those would be more integrated. My point being that this is not an advantage intrinsic to OAuth, just an advantage of using the currently blessed standard. I'll give you that one, if you also agree if that if tomorrow Twitter decided Basic Auth was the way forward, Basic Auth would then be more integrated than OAuth. I meant the process of going to Twitter for a login makes me feel that my application is integrated with them. As oppossed to merely saying, please supply your Twitter name and password to my website. (3) Saves me worrying about SSL. A lot of people are finicky about HTTPS/SSL. This was I can just ytell them that if Twitter wants Oauth that way in future, we will simple provide it. But doesn't that mean that people sniffing on the network where you host your app could potentially grab the authentication tokens of your users as they fly by? Or even just your application tokens if they were interested in spoofing you? I don't mean to be paranoid, but my rather tiny little site was attacked and compromised once a week by evil folks in June -- 4 different attacks by four separate security holes (note to self, don't run a wiki on the same host as my web store). That is a very valuable suggestion. I was thinking of hosting multiple things on the same host, I will avoid that now. These jerks are everywhere now, and they're the real deal. They have a lot of cash and a lot of patience to think of new ways to exploit your resources to their own end. The part I hate about OAuth is that the OAUth page is extremely slow to load and sometimes does not load at all. I see this issue with the Twitter website in general as well, sometime postst from the web just don't go through. I would much appreciate if people at Twitter can address scalability problems to OAUTH, because that I believe is the biggest user turnoff. I've noticed this too. From an outsider layperson's point of view is seems as though we're pushing every authorization request through a single doorway. My hope is that it's more a lack of my
[twitter-dev] Re: OAUTH: Basic Auth is simpler/more reliable/more secure/better received than OAuth!?
I really appreciate your responses. And I definitely understand your point of view now. Paraphrasing: 1. unrelated to basic, oauth is not difficult to implement. i agree. while non-trivial on the desktop simply because no one had done it yet (and released it as OSS), i would agree that it was not especially difficult. 2. passwords can sometime be misused in a cross-site cross-app way. i agree. point taken. especially for the web app world. 3. having twitter included as part of the sign up process feels more integrated. i agree for a web app. and since facebook and flickr do it too, the idiom is well understood. however for a desktop client this is a very abnormal (hopefully just novile?) process -- so i think i would still tend to disagree. thanks again for posting. Isaiah YourHead Software supp...@yourhead.com http://www.yourhead.com On Jul 29, 2009, at 8:42 AM, Amitab wrote: On Jul 28, 4:16 pm, Isaiah supp...@yourhead.com wrote: I publish an open source example of using a OAuth in a standalone mac app -- so I'm bought in to the OAuth idea. But it wasn't easy, I had to fight to make it appear even somewhat integrated, and the lack of security around my apps private keys really freaks me out. On the other hand I see a lot of posts like this where I tilt my head and say, what are you talking about? Because I just don't get where you're coming from. It's like there's some hidden assumption someone forgot to tell me. So, please don't take offense, I'd just like to play devil's advocate and ask you to back up these reasons with some more info. I'll try to be specific about what seems odd, or at least odd to me: I really loved OAuth because: (1) Ease of coding. I could get OAuth working within a couple of days. You're saying that OAuth was easier to implement than basic auth? How so? Basic auth just places the authorization info into the request -- oauth requires the entire token request, token exchange, token inclusion dance. At best I could see someone arguing that it's roughly the same because you can use a nice library either way, but saying OAuth is actually easier seems a bit far fetched. I was merely advocating about OAuth here. I didn't play around with BasicAuth since OAuth was available when I started developing twaller.com. I wanted to respond to comments which said, OAuth is hard to code etc., by saying I didn't feel that way, mainly because I used the library Twitter4J. Saves me any password maintenance, encryption etc. But how do you maintain the user's auth tokens? Since they're basically as powerful as a password (so long as the user has not turned them off) they need to be given the same care, right? In my implementation I save them just like passwords. Are other developers not doing this? If not why not? I think there is a difference. I find passwords messy because if someone wants to misuse them, they can potentially misuse them for other websites beyond twitter. Many people including myself have similar usernames and exactly the same password in multiple websites. So if I accidently leak a password, and someone uses that to login a bank website and make a financial transaction, that will not look very good. Oauth token's are limited to Twitter use. At the moment, i am not encrypting it in my database. (2) Integration with Twitter Branding. With the OAuth scheme, I believe my website is more integrated with Twitter. It would also be nicer if Twitter would maintain their own list of websites they trust with Oauth, just to give users the added confidence that Twitter trusts me. I'm sure if Twitter decided that tomorrow that OAuth was out, and that PAuth or QAuth were the new black, then those would be more integrated. My point being that this is not an advantage intrinsic to OAuth, just an advantage of using the currently blessed standard. I'll give you that one, if you also agree if that if tomorrow Twitter decided Basic Auth was the way forward, Basic Auth would then be more integrated than OAuth. I meant the process of going to Twitter for a login makes me feel that my application is integrated with them. As oppossed to merely saying, please supply your Twitter name and password to my website. (3) Saves me worrying about SSL. A lot of people are finicky about HTTPS/SSL. This was I can just ytell them that if Twitter wants Oauth that way in future, we will simple provide it. But doesn't that mean that people sniffing on the network where you host your app could potentially grab the authentication tokens of your users as they fly by? Or even just your application tokens if they were interested in spoofing you? I don't mean to be paranoid, but my rather tiny little site was attacked and compromised once a week by evil folks in June -- 4 different attacks by four separate security holes (note to self, don't run a wiki on the same host as my web store). That is a very valuable
[twitter-dev] Re: OAUTH: Basic Auth is simpler/more reliable/more secure/better received than OAuth!?
On Wed, Jul 29, 2009 at 3:54 PM, oshells oshe...@gmail.com wrote: I used Abraham examples to implement OAuth into Elgg v0.9.2 (last version of an open source social network platform). It`s working as it should be, but I also made further thinking (if by any chance OAuth gets down) and the first time users join our website they must complete a one time signup process, allowing us to have the missing parts from theyr account (email - any email they might choose) and also let them set theyr username/password . Now, even if theyr password is the same as for twitter it`s md5 encripted and no-one, neither the admins can use it in a non-right way. You realize of course that MD5 is compromised and relatively worthless, right? SHA512 baby. Thanks- - Andy Badera - and...@badera.us - Google me: http://www.google.com/search?q=andrew+badera - This email is: [ ] bloggable [x] ask first [ ] private
[twitter-dev] Re: OAUTH: Basic Auth is simpler/more reliable/more secure/better received than OAuth!?
I used Abraham examples to implement OAuth into Elgg v0.9.2 (last version of an open source social network platform). It`s working as it should be, but I also made further thinking (if by any chance OAuth gets down) and the first time users join our website they must complete a one time signup process, allowing us to have the missing parts from theyr account (email - any email they might choose) and also let them set theyr username/password . Now, even if theyr password is the same as for twitter it`s md5 encripted and no-one, neither the admins can use it in a non-right way. The signup process is by-passed (from the 2nd time they join our website using twitter authentication) by saving the twitter ID into our database linked to the user account (the very 1st time they join), so everytime the user joins using OAuth a session will be created for that unique account (ID), but remember that he can also use username/ password to authenticate into our website. I`ll advice anyone using OAuth to setup this one-time account creation on theyr website (database) too, just in case something bad could ever happen to OAuth. If I`m pleased with OAuth? Hell ya, I do..I love it! Sincerly, Cristian. On Jul 29, 6:42 pm, Amitab hiamita...@gmail.com wrote: On Jul 28, 4:16 pm, Isaiah supp...@yourhead.com wrote: I publish an open source example of using a OAuth in a standalone mac app -- so I'm bought in to the OAuth idea. But it wasn't easy, I had to fight to make it appear even somewhat integrated, and the lack of security around my apps private keys really freaks me out. On the other hand I see a lot of posts like this where I tilt my head and say, what are you talking about? Because I just don't get where you're coming from. It's like there's some hidden assumption someone forgot to tell me. So, please don't take offense, I'd just like to play devil's advocate and ask you to back up these reasons with some more info. I'll try to be specific about what seems odd, or at least odd to me: I really loved OAuth because: (1) Ease of coding. I could get OAuth working within a couple of days. You're saying that OAuth was easier to implement than basic auth? How so? Basic auth just places the authorization info into the request -- oauth requires the entire token request, token exchange, token inclusion dance. At best I could see someone arguing that it's roughly the same because you can use a nice library either way, but saying OAuth is actually easier seems a bit far fetched. I was merely advocating about OAuth here. I didn't play around with BasicAuth since OAuth was available when I started developing twaller.com. I wanted to respond to comments which said, OAuth is hard to code etc., by saying I didn't feel that way, mainly because I used the library Twitter4J. Saves me any password maintenance, encryption etc. But how do you maintain the user's auth tokens? Since they're basically as powerful as a password (so long as the user has not turned them off) they need to be given the same care, right? In my implementation I save them just like passwords. Are other developers not doing this? If not why not? I think there is a difference. I find passwords messy because if someone wants to misuse them, they can potentially misuse them for other websites beyond twitter. Many people including myself have similar usernames and exactly the same password in multiple websites. So if I accidently leak a password, and someone uses that to login a bank website and make a financial transaction, that will not look very good. Oauth token's are limited to Twitter use. At the moment, i am not encrypting it in my database. (2) Integration with Twitter Branding. With the OAuth scheme, I believe my website is more integrated with Twitter. It would also be nicer if Twitter would maintain their own list of websites they trust with Oauth, just to give users the added confidence that Twitter trusts me. I'm sure if Twitter decided that tomorrow that OAuth was out, and that PAuth or QAuth were the new black, then those would be more integrated. My point being that this is not an advantage intrinsic to OAuth, just an advantage of using the currently blessed standard. I'll give you that one, if you also agree if that if tomorrow Twitter decided Basic Auth was the way forward, Basic Auth would then be more integrated than OAuth. I meant the process of going to Twitter for a login makes me feel that my application is integrated with them. As oppossed to merely saying, please supply your Twitter name and password to my website. (3) Saves me worrying about SSL. A lot of people are finicky about HTTPS/SSL. This was I can just ytell them that if Twitter wants Oauth that way in future, we will simple provide it. But doesn't that mean that people sniffing on the network where you
[twitter-dev] Re: OAUTH: Basic Auth is simpler/more reliable/more secure/better received than OAuth!?
OAuth isn't perfect yet. However, it is better from one stand point: If I sign up for a website or program with my twitter password, and it does bad things, I have to change my password in EVERY twitter program I use. With OAuth, I can just block your app. On Jul 28, 9:08 am, Duane Roelands duane.roela...@gmail.com wrote: To be fair, OAuth is better for the user, security-wise, because they never have to provide their Twitter credentials to your application. Basic Auth also provides no way to know that the application is actually who it says it is. OAuth is far from perfect on this front, but it's light-years ahead of Basic. I'm just as agitated about this as anyone, because I think that Twittter's behavior in this specific instance has been sub-par. However, OAuth is still far more secure than Basic Auth On Jul 28, 7:27 am, chinaski007 chinaski...@gmail.com wrote: Let's be honest... The end-result for third-party developers using OAuth appears to be fewer sign-ups, less reliability, more complexity, and potentially less security. Google Optimizer reveals that users are more likely to sign-up for Basic Auth than OAuth. That's just fact. Test it for yourself to confirm. I suppose this is not so weird. Users are accustomed to giving user/ pass information even to foreign apps. It is far more disruptive and invasive for them to go to some bizarre Twitter screen asking them to approve an app. To the average user, what does that mean? (And, heck, it may even require more steps if they have to login again to Twitter.) In terms of reliability, Twitter OAuth was down for days several weeks ago. Tonight yet another unannounced change occurred that broke major code libraries. Meanwhile, Basic Auth has been plugging along just fine and dandy... So what IS the benefit of OAuth? It doesn't benefit developers as you will likely get more sign-ups with Basic Auth and Basic Auth is far, far easier to setup. Sure, OAuth might satisfy some power users hungry for security... But is OAuth even more secure than Basic Auth? Perhaps not. After all, tonight's fix was for an OAuth security flaw known for at least 10+ days (judging by tweets to @twitterapi) that allowed for potential impersonations of credentialed users. On the heels of Twitter's (unofficial) assurance of better communication with developers, this sort of unannounced change is distressing. What's next? (Have Labor Day Weekend plans? You might want to cancel those... just the right time for Twitter to make an unannounced API change!) As for us, we are in the strange position of deprecating OAuth in favor of Basic Auth. Weird, eh?? Okay, we are not totally deprecating OAuth, but we are advising users that Basic Auth is far more robust and reliable. And so our message to new developers: avoid OAuth like the plague. If you must, offer it. But let Basic Auth be your backbone: more reliable, more sign-ups, simpler, and probably just as secure. (Just look at Google Code bug reports about OAuth to get a sense of reliablity.) (Okay, okay, this post was written at 4am after a workday that started at 8am, and after Twitter introduced this new change at 5pm... (hey Twitter, can you introduce major new changes EARLIER in the day so we can react!?!?)... it still doesn't excuse Twitter's continued disregard for the small-to-medium size developer.)
[twitter-dev] Re: OAUTH: Basic Auth is simpler/more reliable/more secure/better received than OAuth!?
On twollo.com I have not seen any issues yet with the changes - no one has ever complained about the Sign in with Twitter option. But I am very glad that Twitter implemented OAuth, I don't have to manage the credentials in the same way - Authenticate using Twitter has been a god send for me, and I am glad I harped on about it for as long as I did, the UX is pretty smooth. From a usage point of view, twollo has about 15000 oauthed users, this is about 30% of the user base. I still provide the option to authenticate using your password (I might remove this soon) - I honestly can't tell why people want to keep giving me their usernames and passwords but they do. If you check http://www.friendboo.com, because I had already implemented Twitter OAuth it was really simple to implement FriendFeeds OAuth - purely because the process is very similar across services - I imagine that this is the case for other services too. I honestly wish Twitter would get out of the oAuth is not meant for production use mindset and really start making people use oAuth. Paul 2009/7/28 chinaski007 chinaski...@gmail.com Let's be honest... The end-result for third-party developers using OAuth appears to be fewer sign-ups, less reliability, more complexity, and potentially less security. Google Optimizer reveals that users are more likely to sign-up for Basic Auth than OAuth. That's just fact. Test it for yourself to confirm. I suppose this is not so weird. Users are accustomed to giving user/ pass information even to foreign apps. It is far more disruptive and invasive for them to go to some bizarre Twitter screen asking them to approve an app. To the average user, what does that mean? (And, heck, it may even require more steps if they have to login again to Twitter.) In terms of reliability, Twitter OAuth was down for days several weeks ago. Tonight yet another unannounced change occurred that broke major code libraries. Meanwhile, Basic Auth has been plugging along just fine and dandy... So what IS the benefit of OAuth? It doesn't benefit developers as you will likely get more sign-ups with Basic Auth and Basic Auth is far, far easier to setup. Sure, OAuth might satisfy some power users hungry for security... But is OAuth even more secure than Basic Auth? Perhaps not. After all, tonight's fix was for an OAuth security flaw known for at least 10+ days (judging by tweets to @twitterapi) that allowed for potential impersonations of credentialed users. On the heels of Twitter's (unofficial) assurance of better communication with developers, this sort of unannounced change is distressing. What's next? (Have Labor Day Weekend plans? You might want to cancel those... just the right time for Twitter to make an unannounced API change!) As for us, we are in the strange position of deprecating OAuth in favor of Basic Auth. Weird, eh?? Okay, we are not totally deprecating OAuth, but we are advising users that Basic Auth is far more robust and reliable. And so our message to new developers: avoid OAuth like the plague. If you must, offer it. But let Basic Auth be your backbone: more reliable, more sign-ups, simpler, and probably just as secure. (Just look at Google Code bug reports about OAuth to get a sense of reliablity.) (Okay, okay, this post was written at 4am after a workday that started at 8am, and after Twitter introduced this new change at 5pm... (hey Twitter, can you introduce major new changes EARLIER in the day so we can react!?!?)... it still doesn't excuse Twitter's continued disregard for the small-to-medium size developer.)
[twitter-dev] Re: OAUTH: Basic Auth is simpler/more reliable/more secure/better received than OAuth!?
On Tue, Jul 28, 2009 at 7:27 AM, chinaski007chinaski...@gmail.com wrote: [the same post three different times] WE GET IT. YOU DON'T LIKE OAUTH. Your (probably statistically insignificant) tests with Google Optimizer reveal that your users are more likely to sign-up for Basic Auth than OAuth. WE GET IT. Did you need to start three different threads to say exactly the same thing on the same day?
[twitter-dev] Re: OAUTH: Basic Auth is simpler/more reliable/more secure/better received than OAuth!?
Although oauth is convoluted and twitter's implementation is buggy, no clear examples and takes time to get it right, I still vote for OAuth. You see people simply don't trust 3rd party apps with their login info as much as they trust the main-application(twitter.com). So at the end of the day, its better for us :)
[twitter-dev] Re: OAUTH: Basic Auth is simpler/more reliable/more secure/better received than OAuth!?
Sorry about that... I deleted those threads before posting this one. I gather you are choosing to receive emails individually. The tests were statistically significant at 95% confidence levels. On Jul 28, 8:09 am, TjL luo...@gmail.com wrote: On Tue, Jul 28, 2009 at 7:27 AM, chinaski007chinaski...@gmail.com wrote: [the same post three different times] WE GET IT. YOU DON'T LIKE OAUTH. Your (probably statistically insignificant) tests with Google Optimizer reveal that your users are more likely to sign-up for Basic Auth than OAuth. WE GET IT. Did you need to start three different threads to say exactly the same thing on the same day?
[twitter-dev] Re: OAUTH: Basic Auth is simpler/more reliable/more secure/better received than OAuth!?
What do you know about your sample, other than they use your app? Are they technically savvy? Mindful of their security? Do they often click on links from Paypal in their email? Do they have friends in Nigeria that are willing to send them money? I think that is the statistical significance to which TjL was referring. At least, I hope so. On Tue, Jul 28, 2009 at 12:12, chinaski007 chinaski...@gmail.com wrote: Sorry about that... I deleted those threads before posting this one. I gather you are choosing to receive emails individually. The tests were statistically significant at 95% confidence levels. On Jul 28, 8:09 am, TjL luo...@gmail.com wrote: On Tue, Jul 28, 2009 at 7:27 AM, chinaski007chinaski...@gmail.com wrote: [the same post three different times] WE GET IT. YOU DON'T LIKE OAUTH. Your (probably statistically insignificant) tests with Google Optimizer reveal that your users are more likely to sign-up for Basic Auth than OAuth. WE GET IT. Did you need to start three different threads to say exactly the same thing on the same day? -- Internets. Serious business.
[twitter-dev] Re: OAUTH: Basic Auth is simpler/more reliable/more secure/better received than OAuth!?
On Tue, Jul 28, 2009 at 2:15 PM, JDG ghil...@gmail.com wrote: I think that is the statistical significance to which TjL was referring. At least, I hope so. I think TjL was referring more to raw population factor than biases. Any one single non-large userbase app is not likely to be statistically predictive of the results you will find across the spectrum of possible apps.
[twitter-dev] Re: OAUTH: Basic Auth is simpler/more reliable/more secure/better received than OAuth!?
That's sort of what I meant, with more references to 419 scammers, my favorite scammers of all. It's hard to imagine ANY app out there to provide a statistically random enough sample to mean anything. If Twitter itself were to perform the survey, I think you'd be more likely to have a random sample, though of course it would be biased towards those of us that enjoy those sorts of surveys. ;) On Tue, Jul 28, 2009 at 12:17, Andrew Badera and...@badera.us wrote: On Tue, Jul 28, 2009 at 2:15 PM, JDG ghil...@gmail.com wrote: I think that is the statistical significance to which TjL was referring. At least, I hope so. I think TjL was referring more to raw population factor than biases. Any one single non-large userbase app is not likely to be statistically predictive of the results you will find across the spectrum of possible apps. -- Internets. Serious business.
[twitter-dev] Re: OAUTH: Basic Auth is simpler/more reliable/more secure/better received than OAuth!?
I haven't done any comprehensive profiling of them. (As well, my particular presentation of the OAuth or Basic login options also may confound the data.) That said, the fact that any sub-population of Twitter users shows a preference for Basic Auth is surprising. I suggest that linking another app to one's Twitter account is foreign and difficult for the average person to understand. The OAuth scare page presented by Twitter doesn't help. It clearly hasn't been split-tested and is poorly executed. It is likely responsible for a significant number of desertions. Compare it, for example, to the Facebook app auth page. Twitter's DENY button is just as big as the ALLOW button; Facebook offers approve and then a much smaller cancel link. Add in the current complexity and unreliability of Twitter OAuth, and, at the very least, offering Basic Auth as an adjunct option seems to make sense. On Jul 28, 11:15 am, JDG ghil...@gmail.com wrote: What do you know about your sample, other than they use your app? Are they technically savvy? Mindful of their security? Do they often click on links from Paypal in their email? Do they have friends in Nigeria that are willing to send them money? I think that is the statistical significance to which TjL was referring. At least, I hope so. On Tue, Jul 28, 2009 at 12:12, chinaski007 chinaski...@gmail.com wrote: Sorry about that... I deleted those threads before posting this one. I gather you are choosing to receive emails individually. The tests were statistically significant at 95% confidence levels. On Jul 28, 8:09 am, TjL luo...@gmail.com wrote: On Tue, Jul 28, 2009 at 7:27 AM, chinaski007chinaski...@gmail.com wrote: [the same post three different times] WE GET IT. YOU DON'T LIKE OAUTH. Your (probably statistically insignificant) tests with Google Optimizer reveal that your users are more likely to sign-up for Basic Auth than OAuth. WE GET IT. Did you need to start three different threads to say exactly the same thing on the same day? -- Internets. Serious business.
[twitter-dev] Re: OAUTH: Basic Auth is simpler/more reliable/more secure/better received than OAuth!?
+1. Unfortunately i have to agree. I´m working with mobile twitter applications and oauth is far for been a good solution. I really hope that twitter team provide us a better solutions to work with mobile or embedded environments where the web browser may not be available or have a limited support. regards, Otávio Ribeiro On Tue, Jul 28, 2009 at 8:27 AM, chinaski007 chinaski...@gmail.com wrote: Let's be honest... The end-result for third-party developers using OAuth appears to be fewer sign-ups, less reliability, more complexity, and potentially less security. Google Optimizer reveals that users are more likely to sign-up for Basic Auth than OAuth. That's just fact. Test it for yourself to confirm. I suppose this is not so weird. Users are accustomed to giving user/ pass information even to foreign apps. It is far more disruptive and invasive for them to go to some bizarre Twitter screen asking them to approve an app. To the average user, what does that mean? (And, heck, it may even require more steps if they have to login again to Twitter.) In terms of reliability, Twitter OAuth was down for days several weeks ago. Tonight yet another unannounced change occurred that broke major code libraries. Meanwhile, Basic Auth has been plugging along just fine and dandy... So what IS the benefit of OAuth? It doesn't benefit developers as you will likely get more sign-ups with Basic Auth and Basic Auth is far, far easier to setup. Sure, OAuth might satisfy some power users hungry for security... But is OAuth even more secure than Basic Auth? Perhaps not. After all, tonight's fix was for an OAuth security flaw known for at least 10+ days (judging by tweets to @twitterapi) that allowed for potential impersonations of credentialed users. On the heels of Twitter's (unofficial) assurance of better communication with developers, this sort of unannounced change is distressing. What's next? (Have Labor Day Weekend plans? You might want to cancel those... just the right time for Twitter to make an unannounced API change!) As for us, we are in the strange position of deprecating OAuth in favor of Basic Auth. Weird, eh?? Okay, we are not totally deprecating OAuth, but we are advising users that Basic Auth is far more robust and reliable. And so our message to new developers: avoid OAuth like the plague. If you must, offer it. But let Basic Auth be your backbone: more reliable, more sign-ups, simpler, and probably just as secure. (Just look at Google Code bug reports about OAuth to get a sense of reliablity.) (Okay, okay, this post was written at 4am after a workday that started at 8am, and after Twitter introduced this new change at 5pm... (hey Twitter, can you introduce major new changes EARLIER in the day so we can react!?!?)... it still doesn't excuse Twitter's continued disregard for the small-to-medium size developer.)
[twitter-dev] Re: OAUTH: Basic Auth is simpler/more reliable/more secure/better received than OAuth!?
On Tue, Jul 28, 2009 at 2:49 PM, chinaski007 chinaski...@gmail.com wrote: I haven't done any comprehensive profiling of them. (As well, my particular presentation of the OAuth or Basic login options also may confound the data.) That said, the fact that any sub-population of Twitter users shows a preference for Basic Auth is surprising. I suggest that linking another app to one's Twitter account is foreign and difficult for the average person to understand. The OAuth scare page presented by Twitter doesn't help. It clearly hasn't been split-tested and is poorly executed. It is likely responsible for a significant number of desertions. Compare it, for example, to the Facebook app auth page. Twitter's DENY button is just as big as the ALLOW button; Facebook offers approve and then a much smaller cancel link. Add in the current complexity and unreliability of Twitter OAuth, and, at the very least, offering Basic Auth as an adjunct option seems to make sense. OAuth IS unfamiliar, YES. OAuth DOES ask more of the user, YES. Like anything else new in technology, the better you educate your user, both implicitly and explicitly, about the process, the better the adoption rate is bound to be for a useful or required innovation. In other words, handholding and spoonfeeding your users through the OAuth process is going to give you better conversion rates than simply bouncing them to Twitter with little or no notification or education. --ab
[twitter-dev] Re: OAUTH: Basic Auth is simpler/more reliable/more secure/better received than OAuth!?
OAuth IS unfamiliar, YES. OAuth DOES ask more of the user, YES. So what's the upside for the third-party developer? In terms of security, we've already seen how OAuth-like applications in, e.g., Facebook have led to massive hacker/phishing/etc problems. While OAuth solves one leg of the security problem (not actually having their password), OAuth'd apps still have complete API access to the account and can run rampant before the user realizes or figures out how to revoke credentials.
[twitter-dev] Re: OAUTH: Basic Auth is simpler/more reliable/more secure/better received than OAuth!?
Sorry about your Oauth Implementation, Mine's been working steadily with no hiccups: Lot's of very solid implementations out there. As far as the user sign-up problem, Yeah, I agree, It's a bit of a scare for the user to have to connect to an off-site twitter authority page -- But that's what Facebook, paypal and all the big boys are pushing toward. As Robert Palmer once said: Your gonna have to face it, your addicted to passwords. Jim On Jul 28, 1:27 am, chinaski007 chinaski...@gmail.com wrote: Let's be honest... The end-result for third-party developers using OAuth appears to be fewer sign-ups, less reliability, more complexity, and potentially less security. Google Optimizer reveals that users are more likely to sign-up for Basic Auth than OAuth. That's just fact. Test it for yourself to confirm. I suppose this is not so weird. Users are accustomed to giving user/ pass information even to foreign apps. It is far more disruptive and invasive for them to go to some bizarre Twitter screen asking them to approve an app. To the average user, what does that mean? (And, heck, it may even require more steps if they have to login again to Twitter.) In terms of reliability, Twitter OAuth was down for days several weeks ago. Tonight yet another unannounced change occurred that broke major code libraries. Meanwhile, Basic Auth has been plugging along just fine and dandy... So what IS the benefit of OAuth? It doesn't benefit developers as you will likely get more sign-ups with Basic Auth and Basic Auth is far, far easier to setup. Sure, OAuth might satisfy some power users hungry for security... But is OAuth even more secure than Basic Auth? Perhaps not. After all, tonight's fix was for an OAuth security flaw known for at least 10+ days (judging by tweets to @twitterapi) that allowed for potential impersonations of credentialed users. On the heels of Twitter's (unofficial) assurance of better communication with developers, this sort of unannounced change is distressing. What's next? (Have Labor Day Weekend plans? You might want to cancel those... just the right time for Twitter to make an unannounced API change!) As for us, we are in the strange position of deprecating OAuth in favor of Basic Auth. Weird, eh?? Okay, we are not totally deprecating OAuth, but we are advising users that Basic Auth is far more robust and reliable. And so our message to new developers: avoid OAuth like the plague. If you must, offer it. But let Basic Auth be your backbone: more reliable, more sign-ups, simpler, and probably just as secure. (Just look at Google Code bug reports about OAuth to get a sense of reliablity.) (Okay, okay, this post was written at 4am after a workday that started at 8am, and after Twitter introduced this new change at 5pm... (hey Twitter, can you introduce major new changes EARLIER in the day so we can react!?!?)... it still doesn't excuse Twitter's continued disregard for the small-to-medium size developer.)
[twitter-dev] Re: OAUTH: Basic Auth is simpler/more reliable/more secure/better received than OAuth!?
It's only a scare if the development community neglects or refuses to educate the populace at large that only Twitter really needs your password, so why give it to anyone else? On Tue, Jul 28, 2009 at 13:27, jahbini jahb...@celarien.com wrote: Sorry about your Oauth Implementation, Mine's been working steadily with no hiccups: Lot's of very solid implementations out there. As far as the user sign-up problem, Yeah, I agree, It's a bit of a scare for the user to have to connect to an off-site twitter authority page -- But that's what Facebook, paypal and all the big boys are pushing toward. As Robert Palmer once said: Your gonna have to face it, your addicted to passwords. Jim On Jul 28, 1:27 am, chinaski007 chinaski...@gmail.com wrote: Let's be honest... The end-result for third-party developers using OAuth appears to be fewer sign-ups, less reliability, more complexity, and potentially less security. Google Optimizer reveals that users are more likely to sign-up for Basic Auth than OAuth. That's just fact. Test it for yourself to confirm. I suppose this is not so weird. Users are accustomed to giving user/ pass information even to foreign apps. It is far more disruptive and invasive for them to go to some bizarre Twitter screen asking them to approve an app. To the average user, what does that mean? (And, heck, it may even require more steps if they have to login again to Twitter.) In terms of reliability, Twitter OAuth was down for days several weeks ago. Tonight yet another unannounced change occurred that broke major code libraries. Meanwhile, Basic Auth has been plugging along just fine and dandy... So what IS the benefit of OAuth? It doesn't benefit developers as you will likely get more sign-ups with Basic Auth and Basic Auth is far, far easier to setup. Sure, OAuth might satisfy some power users hungry for security... But is OAuth even more secure than Basic Auth? Perhaps not. After all, tonight's fix was for an OAuth security flaw known for at least 10+ days (judging by tweets to @twitterapi) that allowed for potential impersonations of credentialed users. On the heels of Twitter's (unofficial) assurance of better communication with developers, this sort of unannounced change is distressing. What's next? (Have Labor Day Weekend plans? You might want to cancel those... just the right time for Twitter to make an unannounced API change!) As for us, we are in the strange position of deprecating OAuth in favor of Basic Auth. Weird, eh?? Okay, we are not totally deprecating OAuth, but we are advising users that Basic Auth is far more robust and reliable. And so our message to new developers: avoid OAuth like the plague. If you must, offer it. But let Basic Auth be your backbone: more reliable, more sign-ups, simpler, and probably just as secure. (Just look at Google Code bug reports about OAuth to get a sense of reliablity.) (Okay, okay, this post was written at 4am after a workday that started at 8am, and after Twitter introduced this new change at 5pm... (hey Twitter, can you introduce major new changes EARLIER in the day so we can react!?!?)... it still doesn't excuse Twitter's continued disregard for the small-to-medium size developer.) -- Internets. Serious business.
[twitter-dev] Re: OAUTH: Basic Auth is simpler/more reliable/more secure/better received than OAuth!?
As a developer who has recent launched Twaller (http:// www.twaller.com) which supports OAuth, I think I should share my perspective on this. I really loved OAuth because: (1) Ease of coding. I could get OAuth working within a couple of days. Saves me any password maintenance, encryption etc. (2) Integration with Twitter Branding. With the OAuth scheme, I believe my website is more integrated with Twitter. It would also be nicer if Twitter would maintain their own list of websites they trust with Oauth, just to give users the added confidence that Twitter trusts me. (3) Saves me worrying about SSL. A lot of people are finicky about HTTPS/SSL. This was I can just ytell them that if Twitter wants Oauth that way in future, we will simple provide it. The part I hate about OAuth is that the OAUth page is extremely slow to load and sometimes does not load at all. I see this issue with the Twitter website in general as well, sometime postst from the web just don't go through. I would much appreciate if people at Twitter can address scalability problems to OAUTH, because that I believe is the biggest user turnoff. On Jul 28, 1:11 pm, JDG ghil...@gmail.com wrote: It's only a scare if the development community neglects or refuses to educate the populace at large that only Twitter really needs your password, so why give it to anyone else? On Tue, Jul 28, 2009 at 13:27, jahbini jahb...@celarien.com wrote: Sorry about your Oauth Implementation, Mine's been working steadily with no hiccups: Lot's of very solid implementations out there. As far as the user sign-up problem, Yeah, I agree, It's a bit of a scare for the user to have to connect to an off-site twitter authority page -- But that's what Facebook, paypal and all the big boys are pushing toward. As Robert Palmer once said: Your gonna have to face it, your addicted to passwords. Jim On Jul 28, 1:27 am, chinaski007 chinaski...@gmail.com wrote: Let's be honest... The end-result for third-party developers using OAuth appears to be fewer sign-ups, less reliability, more complexity, and potentially less security. Google Optimizer reveals that users are more likely to sign-up for Basic Auth than OAuth. That's just fact. Test it for yourself to confirm. I suppose this is not so weird. Users are accustomed to giving user/ pass information even to foreign apps. It is far more disruptive and invasive for them to go to some bizarre Twitter screen asking them to approve an app. To the average user, what does that mean? (And, heck, it may even require more steps if they have to login again to Twitter.) In terms of reliability, Twitter OAuth was down for days several weeks ago. Tonight yet another unannounced change occurred that broke major code libraries. Meanwhile, Basic Auth has been plugging along just fine and dandy... So what IS the benefit of OAuth? It doesn't benefit developers as you will likely get more sign-ups with Basic Auth and Basic Auth is far, far easier to setup. Sure, OAuth might satisfy some power users hungry for security... But is OAuth even more secure than Basic Auth? Perhaps not. After all, tonight's fix was for an OAuth security flaw known for at least 10+ days (judging by tweets to @twitterapi) that allowed for potential impersonations of credentialed users. On the heels of Twitter's (unofficial) assurance of better communication with developers, this sort of unannounced change is distressing. What's next? (Have Labor Day Weekend plans? You might want to cancel those... just the right time for Twitter to make an unannounced API change!) As for us, we are in the strange position of deprecating OAuth in favor of Basic Auth. Weird, eh?? Okay, we are not totally deprecating OAuth, but we are advising users that Basic Auth is far more robust and reliable. And so our message to new developers: avoid OAuth like the plague. If you must, offer it. But let Basic Auth be your backbone: more reliable, more sign-ups, simpler, and probably just as secure. (Just look at Google Code bug reports about OAuth to get a sense of reliablity.) (Okay, okay, this post was written at 4am after a workday that started at 8am, and after Twitter introduced this new change at 5pm... (hey Twitter, can you introduce major new changes EARLIER in the day so we can react!?!?)... it still doesn't excuse Twitter's continued disregard for the small-to-medium size developer.) -- Internets. Serious business.
[twitter-dev] Re: OAUTH: Basic Auth is simpler/more reliable/more secure/better received than OAuth!?
Funny, I posted about our high success rate (95% of all users) with OAuth. I'm trying to get a feel for if we're fortunate, have a good flow or everyone has the same rates. http://groups.google.com/group/twitter-development-talk/browse_thread/thread/da46cd261fa13bca?hl=en On Jul 28, 2:13 pm, Amitab hiamita...@gmail.com wrote: As a developer who has recent launched Twaller (http://www.twaller.com) which supports OAuth, I think I should share my perspective on this. I really loved OAuth because: (1) Ease of coding. I could get OAuth working within a couple of days. Saves me any password maintenance, encryption etc. (2) Integration with Twitter Branding. With the OAuth scheme, I believe my website is more integrated with Twitter. It would also be nicer if Twitter would maintain their own list of websites they trust with Oauth, just to give users the added confidence that Twitter trusts me. (3) Saves me worrying about SSL. A lot of people are finicky about HTTPS/SSL. This was I can just ytell them that if Twitter wants Oauth that way in future, we will simple provide it. The part I hate about OAuth is that the OAUth page is extremely slow to load and sometimes does not load at all. I see this issue with the Twitter website in general as well, sometime postst from the web just don't go through. I would much appreciate if people at Twitter can address scalability problems to OAUTH, because that I believe is the biggest user turnoff. On Jul 28, 1:11 pm, JDG ghil...@gmail.com wrote: It's only a scare if the development community neglects or refuses to educate the populace at large that only Twitter really needs your password, so why give it to anyone else? On Tue, Jul 28, 2009 at 13:27, jahbini jahb...@celarien.com wrote: Sorry about your Oauth Implementation, Mine's been working steadily with no hiccups: Lot's of very solid implementations out there. As far as the user sign-up problem, Yeah, I agree, It's a bit of a scare for the user to have to connect to an off-site twitter authority page -- But that's what Facebook, paypal and all the big boys are pushing toward. As Robert Palmer once said: Your gonna have to face it, your addicted to passwords. Jim On Jul 28, 1:27 am, chinaski007 chinaski...@gmail.com wrote: Let's be honest... The end-result for third-party developers using OAuth appears to be fewer sign-ups, less reliability, more complexity, and potentially less security. Google Optimizer reveals that users are more likely to sign-up for Basic Auth than OAuth. That's just fact. Test it for yourself to confirm. I suppose this is not so weird. Users are accustomed to giving user/ pass information even to foreign apps. It is far more disruptive and invasive for them to go to some bizarre Twitter screen asking them to approve an app. To the average user, what does that mean? (And, heck, it may even require more steps if they have to login again to Twitter.) In terms of reliability, Twitter OAuth was down for days several weeks ago. Tonight yet another unannounced change occurred that broke major code libraries. Meanwhile, Basic Auth has been plugging along just fine and dandy... So what IS the benefit of OAuth? It doesn't benefit developers as you will likely get more sign-ups with Basic Auth and Basic Auth is far, far easier to setup. Sure, OAuth might satisfy some power users hungry for security... But is OAuth even more secure than Basic Auth? Perhaps not. After all, tonight's fix was for an OAuth security flaw known for at least 10+ days (judging by tweets to @twitterapi) that allowed for potential impersonations of credentialed users. On the heels of Twitter's (unofficial) assurance of better communication with developers, this sort of unannounced change is distressing. What's next? (Have Labor Day Weekend plans? You might want to cancel those... just the right time for Twitter to make an unannounced API change!) As for us, we are in the strange position of deprecating OAuth in favor of Basic Auth. Weird, eh?? Okay, we are not totally deprecating OAuth, but we are advising users that Basic Auth is far more robust and reliable. And so our message to new developers: avoid OAuth like the plague. If you must, offer it. But let Basic Auth be your backbone: more reliable, more sign-ups, simpler, and probably just as secure. (Just look at Google Code bug reports about OAuth to get a sense of reliablity.) (Okay, okay, this post was written at 4am after a workday that started at 8am, and after Twitter introduced this new change at 5pm... (hey Twitter, can you introduce major new changes EARLIER in the day so we can react!?!?)... it still doesn't excuse Twitter's continued disregard for the small-to-medium size developer.) --
[twitter-dev] Re: OAUTH: Basic Auth is simpler/more reliable/more secure/better received than OAuth!?
I publish an open source example of using a OAuth in a standalone mac app -- so I'm bought in to the OAuth idea. But it wasn't easy, I had to fight to make it appear even somewhat integrated, and the lack of security around my apps private keys really freaks me out. On the other hand I see a lot of posts like this where I tilt my head and say, what are you talking about? Because I just don't get where you're coming from. It's like there's some hidden assumption someone forgot to tell me. So, please don't take offense, I'd just like to play devil's advocate and ask you to back up these reasons with some more info. I'll try to be specific about what seems odd, or at least odd to me: I really loved OAuth because: (1) Ease of coding. I could get OAuth working within a couple of days. You're saying that OAuth was easier to implement than basic auth? How so? Basic auth just places the authorization info into the request -- oauth requires the entire token request, token exchange, token inclusion dance. At best I could see someone arguing that it's roughly the same because you can use a nice library either way, but saying OAuth is actually easier seems a bit far fetched. Saves me any password maintenance, encryption etc. But how do you maintain the user's auth tokens? Since they're basically as powerful as a password (so long as the user has not turned them off) they need to be given the same care, right? In my implementation I save them just like passwords. Are other developers not doing this? If not why not? (2) Integration with Twitter Branding. With the OAuth scheme, I believe my website is more integrated with Twitter. It would also be nicer if Twitter would maintain their own list of websites they trust with Oauth, just to give users the added confidence that Twitter trusts me. I'm sure if Twitter decided that tomorrow that OAuth was out, and that PAuth or QAuth were the new black, then those would be more integrated. My point being that this is not an advantage intrinsic to OAuth, just an advantage of using the currently blessed standard. I'll give you that one, if you also agree if that if tomorrow Twitter decided Basic Auth was the way forward, Basic Auth would then be more integrated than OAuth. (3) Saves me worrying about SSL. A lot of people are finicky about HTTPS/SSL. This was I can just ytell them that if Twitter wants Oauth that way in future, we will simple provide it. But doesn't that mean that people sniffing on the network where you host your app could potentially grab the authentication tokens of your users as they fly by? Or even just your application tokens if they were interested in spoofing you? I don't mean to be paranoid, but my rather tiny little site was attacked and compromised once a week by evil folks in June -- 4 different attacks by four separate security holes (note to self, don't run a wiki on the same host as my web store). These jerks are everywhere now, and they're the real deal. They have a lot of cash and a lot of patience to think of new ways to exploit your resources to their own end. The part I hate about OAuth is that the OAUth page is extremely slow to load and sometimes does not load at all. I see this issue with the Twitter website in general as well, sometime postst from the web just don't go through. I would much appreciate if people at Twitter can address scalability problems to OAUTH, because that I believe is the biggest user turnoff. I've noticed this too. From an outsider layperson's point of view is seems as though we're pushing every authorization request through a single doorway. My hope is that it's more a lack of my understanding, than anything else. Right? Right?!?! ;-) Thanks for hearing my devil's advocate argument. Don't feel compelled to respond. I don't *need* answers, just curious, that's all. Isaiah
[twitter-dev] Re: OAUTH: Basic Auth is simpler/more reliable/more secure/better received than OAuth!?
We had much lower rates. But it is difficult to disentangle if that is due to the extra steps required for OAuth, the OAuth scare screen on Twitter.com, or because of the copy we initially used to invite users to use OAuth. (For example, we had text that read add your Twitter account via OAuth which admittedly isn't going to be very well understand by the average user... login with Twitter would be better.) But for the last 3282 users who added accounts in our system, and for whom we offered BOTH OAuth and Basic Auth options (and where the OAuth step was clearer, indicating that they wouldn't have to give us user/ pass), 1209 or 36% chose OAuth. While this might again be confounded by other factors, this does suggest that for our app, at least, given the choice between Basic and OAuth, users show a preference for Basic Auth. On reflection (and after some sleep), I admit that my initial post was a bit hyperbolic, and partly due to my frustration dealing with another unannounced API change. That said, at least for us, evidence bears out that Basic Auth is just as accepted, if not more accepted, than OAuth by our users. On Jul 28, 3:58 pm, jmathai jmat...@gmail.com wrote: Funny, I posted about our high success rate (95% of all users) with OAuth. I'm trying to get a feel for if we're fortunate, have a good flow or everyone has the same rates.http://groups.google.com/group/twitter-development-talk/browse_thread... On Jul 28, 2:13 pm, Amitab hiamita...@gmail.com wrote: As a developer who has recent launched Twaller (http://www.twaller.com) which supports OAuth, I think I should share my perspective on this. I really loved OAuth because: (1) Ease of coding. I could get OAuth working within a couple of days. Saves me any password maintenance, encryption etc. (2) Integration with Twitter Branding. With the OAuth scheme, I believe my website is more integrated with Twitter. It would also be nicer if Twitter would maintain their own list of websites they trust with Oauth, just to give users the added confidence that Twitter trusts me. (3) Saves me worrying about SSL. A lot of people are finicky about HTTPS/SSL. This was I can just ytell them that if Twitter wants Oauth that way in future, we will simple provide it. The part I hate about OAuth is that the OAUth page is extremely slow to load and sometimes does not load at all. I see this issue with the Twitter website in general as well, sometime postst from the web just don't go through. I would much appreciate if people at Twitter can address scalability problems to OAUTH, because that I believe is the biggest user turnoff. On Jul 28, 1:11 pm, JDG ghil...@gmail.com wrote: It's only a scare if the development community neglects or refuses to educate the populace at large that only Twitter really needs your password, so why give it to anyone else? On Tue, Jul 28, 2009 at 13:27, jahbini jahb...@celarien.com wrote: Sorry about your Oauth Implementation, Mine's been working steadily with no hiccups: Lot's of very solid implementations out there. As far as the user sign-up problem, Yeah, I agree, It's a bit of a scare for the user to have to connect to an off-site twitter authority page -- But that's what Facebook, paypal and all the big boys are pushing toward. As Robert Palmer once said: Your gonna have to face it, your addicted to passwords. Jim On Jul 28, 1:27 am, chinaski007 chinaski...@gmail.com wrote: Let's be honest... The end-result for third-party developers using OAuth appears to be fewer sign-ups, less reliability, more complexity, and potentially less security. Google Optimizer reveals that users are more likely to sign-up for Basic Auth than OAuth. That's just fact. Test it for yourself to confirm. I suppose this is not so weird. Users are accustomed to giving user/ pass information even to foreign apps. It is far more disruptive and invasive for them to go to some bizarre Twitter screen asking them to approve an app. To the average user, what does that mean? (And, heck, it may even require more steps if they have to login again to Twitter.) In terms of reliability, Twitter OAuth was down for days several weeks ago. Tonight yet another unannounced change occurred that broke major code libraries. Meanwhile, Basic Auth has been plugging along just fine and dandy... So what IS the benefit of OAuth? It doesn't benefit developers as you will likely get more sign-ups with Basic Auth and Basic Auth is far, far easier to setup. Sure, OAuth might satisfy some power users hungry for security... But is OAuth even more secure than Basic Auth? Perhaps not. After all, tonight's fix was for an OAuth security flaw known for at least 10+ days (judging by tweets to @twitterapi) that allowed for potential
