A couple of days ago, after the launch of Hahlo 3, someone posted that
Hahlo is "insecure" because it stores the username/password in a
cookie on your iPhone. Personally I think its not that big of an issue
(its just a twitter password, its not bank account details or
anything), and what he fails to mention is that every twitter iphone
app does exactly the same thing.
I tried (even though I was doubtful it would work) to md5 the password
before saving it in the cookie, which would counteract the "issue".
However it then doesn't work when you try to use it to authenticate
against the api (as expected)
Is there anyway that I can authenticate against the API with something
other than the raw password? ie, can you make it possible to login
using an md5 hashed password or something better?
We've looked into providing an alternative to HTTP Basic Auth in the short term, but due to our password storage technique we're unable to accept a salted hash as the basis of authentication. Our long-term solution here is still OAuth.
> A couple of days ago, after the launch of Hahlo 3, someone posted that > Hahlo is "insecure" because it stores the username/password in a > cookie on your iPhone. Personally I think its not that big of an issue > (its just a twitter password, its not bank account details or > anything), and what he fails to mention is that every twitter iphone > app does exactly the same thing.
> I tried (even though I was doubtful it would work) to md5 the password > before saving it in the cookie, which would counteract the "issue". > However it then doesn't work when you try to use it to authenticate > against the api (as expected)
> Is there anyway that I can authenticate against the API with something > other than the raw password? ie, can you make it possible to login > using an md5 hashed password or something better?
Lemme put on my 10 gallon security "expert" hat here...
Do you really have to store the username and pass in the cookie? Hahlo is, if I remember, a web app, so you should be able to just store the username and pass server-side in the session data. The cookie would only need to store a session ID.
If you really *have* to store your data in the cookie, you should be able to encrypt your cookie data with a two-way hash. It's not optimal (you should never store authentication data in the cookie, encrypted or not), but it will make stealing the data significantly harder.
Does Safari on the iPhone support HTTPS-only cookies? If so, I would be using those as well (again, if you really HAVE to store usernames and passwords in the cookie).
Remember that *lots* of (most?) people only use a handful of usernames and passwords for numerous accounts. A lost iPhone or an unknown XSS exploit in Hahlo or Twitter could cause big, embarrassing trouble.
You can ping me offlist if you wanted to discuss this further, since the issues are a bit outside scope.
> A couple of days ago, after the launch of Hahlo 3, someone posted that > Hahlo is "insecure" because it stores the username/password in a > cookie on your iPhone. Personally I think its not that big of an issue > (its just a twitter password, its not bank account details or > anything), and what he fails to mention is that every twitter iphone > app does exactly the same thing.
> I tried (even though I was doubtful it would work) to md5 the password > before saving it in the cookie, which would counteract the "issue". > However it then doesn't work when you try to use it to authenticate > against the api (as expected)
> Is there anyway that I can authenticate against the API with something > other than the raw password? ie, can you make it possible to login > using an md5 hashed password or something better?
Thanks for the response, I'm going to have to take a good look at my
auth code, its not something I wrote myself, its a modified script I
got from elsewhere. I should be able to switch it to session data
instead, but I need to make sure I can do it without interuptting my
users too much. Looks like I'm not going to escape from working on
Hahlo just yet.
cheers
On May 7, 1:02 pm, "Ed Finkler" <funkat...@gmail.com> wrote:
> Lemme put on my 10 gallon security "expert" hat here...
> Do you really have to store the username and pass in the cookie? Hahlo
> is, if I remember, a web app, so you should be able to just store the
> username and pass server-side in the session data. The cookie would
> only need to store a session ID.
> If you really *have* to store your data in the cookie, you should be
> able to encrypt your cookie data with a two-way hash. It's not optimal
> (you should never store authentication data in the cookie, encrypted
> or not), but it will make stealing the data significantly harder.
> Does Safari on the iPhone support HTTPS-only cookies? If so, I would
> be using those as well (again, if you really HAVE to store usernames
> and passwords in the cookie).
> Remember that *lots* of (most?) people only use a handful of usernames
> and passwords for numerous accounts. A lost iPhone or an unknown XSS
> exploit in Hahlo or Twitter could cause big, embarrassing trouble.
> You can ping me offlist if you wanted to discuss this further, since
> the issues are a bit outside scope.
> > A couple of days ago, after the launch of Hahlo 3, someone posted that
> > Hahlo is "insecure" because it stores the username/password in a
> > cookie on your iPhone. Personally I think its not that big of an issue
> > (its just a twitter password, its not bank account details or
> > anything), and what he fails to mention is that every twitter iphone
> > app does exactly the same thing.
> > I tried (even though I was doubtful it would work) to md5 the password
> > before saving it in the cookie, which would counteract the "issue".
> > However it then doesn't work when you try to use it to authenticate
> > against the api (as expected)
> > Is there anyway that I can authenticate against the API with something
> > other than the raw password? ie, can you make it possible to login
> > using an md5 hashed password or something better?
Ok, it got the better of me I had to fix it. I've re-written just
about all my authentication stuff to only use php sessions, all
information previously being stored in cookies is now in sessions
variables instead. I've been fiddling with if for the past few hours
and it appears to be working ok for me, but I would really appreciate
it if a few of you could jump over to http://old.hahlo.com (no iPhone
required) , login and play around to check it out for me.
Once I get this out Hahlo should be the only third party mobile
twitter client/webapp not storing raw auth details in a cookie.
<Dean.J.Robin...@gmail.com> wrote: > Once I get this out Hahlo should be the only third party mobile > twitter client/webapp not storing raw auth details in a cookie.
On May 7, 2008, at 9:54 AM, dean.j.robinson wrote:
> Ok, it got the better of me I had to fix it. I've re-written just > about all my authentication stuff to only use php sessions, all > information previously being stored in cookies is now in sessions > variables instead. I've been fiddling with if for the past few hours > and it appears to be working ok for me, but I would really appreciate > it if a few of you could jump over to http://old.hahlo.com (no iPhone > required) , login and play around to check it out for me.
> Once I get this out Hahlo should be the only third party mobile > twitter client/webapp not storing raw auth details in a cookie.
> cheers
> Dean
Works for me. Thanks for taking the security seriously; best to do the right thing the first time. I wish https was used for the login screen, but at least the potential for assuming someone's social identity (say by a top100 Twitterer) and broadcasting a tinyurl pointing towards a driveby-malware-serving site has been minimized. Hopefully others will follow your lead.
Your solution sounds like an improvement, but not ideal. Now if your
server is compromised, with it will go all your users twitter
credentials (correct me if I'm misunderstand your solution).
Here's how Quotably handles authentication:
1) use SSL for the login page
2) use a 2-way encryption algorithm on the credential cookies, like
Blowfish
I think this is the best approach until OAuth becomes viable.
Thanks for addressing this! I really appreciate you taking it
seriously. I know it doesn't seem like twitter credentials are that
important. But remember a twitter account is a direct route to a lot
of people's eyes, and could cause some serious embarrassment if
nothing else for the user who has their account compromised.
-Ben
On May 7, 9:54 am, "dean.j.robinson" <Dean.J.Robin...@gmail.com>
wrote:
> Ok, it got the better of me I had to fix it. I've re-written just
> about all my authentication stuff to only use php sessions, all
> information previously being stored in cookies is now in sessions
> variables instead. I've been fiddling with if for the past few hours
> and it appears to be working ok for me, but I would really appreciate
> it if a few of you could jump over tohttp://old.hahlo.com(no iPhone
> required) , login and play around to check it out for me.
> Once I get this out Hahlo should be the only third party mobile
> twitter client/webapp not storing raw auth details in a cookie.
In addition to the switch from cookies to session vars, I am also
encrypting the password using one of the encryption functions
available in my php install. I did also encrypt the username, but it
broke a few things, I should be able to solve that when I get time.
I'll check out the ssl bit when my hosting admin panel comes back
online...
cheers
Dean
On May 8, 8:16 am, Benjamin Tucker <btuc...@gmail.com> wrote:
> Your solution sounds like an improvement, but not ideal. Now if your
> server is compromised, with it will go all your users twitter
> credentials (correct me if I'm misunderstand your solution).
> Here's how Quotably handles authentication:
> 1) use SSL for the login page
> 2) use a 2-way encryption algorithm on the credential cookies, like
> Blowfish
> I think this is the best approach until OAuth becomes viable.
> Thanks for addressing this! I really appreciate you taking it
> seriously. I know it doesn't seem like twitter credentials are that
> important. But remember a twitter account is a direct route to a lot
> of people's eyes, and could cause some serious embarrassment if
> nothing else for the user who has their account compromised.
> -Ben
> On May 7, 9:54 am, "dean.j.robinson" <Dean.J.Robin...@gmail.com>
> wrote:
> > Ok, it got the better of me I had to fix it. I've re-written just
> > about all my authentication stuff to only use php sessions, all
> > information previously being stored in cookies is now in sessions
> > variables instead. I've been fiddling with if for the past few hours
> > and it appears to be working ok for me, but I would really appreciate
> > it if a few of you could jump over tohttp://old.hahlo.com(noiPhone > > required) , login and play around to check it out for me.
> > Once I get this out Hahlo should be the only third party mobile
> > twitter client/webapp not storing raw auth details in a cookie.
Cool. Just don't store the encrypted password in session data stored
on the server (there's really little reason to encrypt it if you do
that since an attacker could read it using the same mechanism as your
code). What you want is to store it in the cookie on the client.
Keep up the good work. Hahlo really does rock!
-Ben
On May 7, 7:52 pm, "dean.j.robinson" <Dean.J.Robin...@gmail.com>
wrote:
> In addition to the switch from cookies to session vars, I am also
> encrypting the password using one of the encryption functions
> available in my php install. I did also encrypt the username, but it
> broke a few things, I should be able to solve that when I get time.
> I'll check out the ssl bit when my hosting admin panel comes back
> online...
> cheers
> Dean
> On May 8, 8:16 am, Benjamin Tucker <btuc...@gmail.com> wrote:
> > Your solution sounds like an improvement, but not ideal. Now if your
> > server is compromised, with it will go all your users twitter
> > credentials (correct me if I'm misunderstand your solution).
> > Here's how Quotably handles authentication:
> > 1) use SSL for the login page
> > 2) use a 2-way encryption algorithm on the credential cookies, like
> > Blowfish
> > I think this is the best approach until OAuth becomes viable.
> > Thanks for addressing this! I really appreciate you taking it
> > seriously. I know it doesn't seem like twitter credentials are that
> > important. But remember a twitter account is a direct route to a lot
> > of people's eyes, and could cause some serious embarrassment if
> > nothing else for the user who has their account compromised.
> > -Ben
> > On May 7, 9:54 am, "dean.j.robinson" <Dean.J.Robin...@gmail.com>
> > wrote:
> > > Ok, it got the better of me I had to fix it. I've re-written just
> > > about all my authentication stuff to only use php sessions, all
> > > information previously being stored in cookies is now in sessions
> > > variables instead. I've been fiddling with if for the past few hours
> > > and it appears to be working ok for me, but I would really appreciate
> > > it if a few of you could jump over tohttp://old.hahlo.com(noiPhone > > > required) , login and play around to check it out for me.
> > > Once I get this out Hahlo should be the only third party mobile
> > > twitter client/webapp not storing raw auth details in a cookie.
