On Fri, Jul 31, 2009 at 21:02, Bradley S. O'Hearne
wrote:
>
> 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 requi
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:
> Yo
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 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
>
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 wrote:
> Jesse,
> That is not true. With the Sign in with Twitter flow (not the standard
> OAuth flow wh
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,
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 ba
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,
Another way to look at it, from the opposite angle: If I change my Twitter
password on Twitter's site, my app will continue to work without additional
interaction if it's coded with OAuth.
On Fri, Jul 31, 2009 at 08:41, Christopher St John wrote:
>
> On Thu, Jul 30, 2009 at 6:07 PM, Bradley S.
>
On Thu, Jul 30, 2009 at 6:07 PM, Bradley S.
O'Hearne 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
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 t
"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 (or
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'
On Jul 30, 7:40 pm, "Bradley S. O'Hearne"
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
> g
On Jul 31, 4:37 am, Duane Roelands 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.
>
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 prov
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
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, "B
You can lead a horse to water ...
On Thu, Jul 30, 2009 at 7:07 PM, Bradley S. O'Hearne 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
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 deba
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.
Bas
On Thu, Jul 30, 2009 at 11:40 AM, Bradley S. O'Hearne <
brad.ohea...@gmail.com> wrote:
>
> *snip*
A ... have you missed the last 12 months of Twitterverse drama? You
can't trust random third party apps who demand your credentials. How do we
know what they'll do with it? There was a breach ju
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 OAut
On Jul 28, 3:27 pm, chinaski007 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
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
On Wed, Jul 29, 2009 at 3:54 PM, oshells 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 use
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
On Jul 28, 4:16 pm, Isaiah 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 r
Well said, Duane.
Thanks,
Doug
On Wed, Jul 29, 2009 at 7:18 AM, Duane Roelands 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 expect
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
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.
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
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
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, Ami
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
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 wrote:
>
> Sorry about your Oauth Implementation, Mine's been working steadily
>
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 Fac
> 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 secu
On Tue, Jul 28, 2009 at 2:49 PM, chinaski007 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
> prefe
+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.
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
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
On Tue, Jul 28, 2009 at 2:15 PM, JDG 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
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 w
On Tue, Jul 28, 2009 at 2:12 PM, chinaski007 wrote:
> I gather you are choosing to receive emails individually.
>
As are a large number of us on this list.
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 wrote:
> On Tue, Jul 28, 2009 at 7:27 AM, chinaski007 wrote:
> > [the same p
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, it
On Tue, Jul 28, 2009 at 7:27 AM, chinaski007 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
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
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 wr
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 ahea
50 matches
Mail list logo
