Sending encoded login details to API
dean.j.robinson
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?
Does anyone else have any suggestions?
Alex Payne
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.
--
Alex Payne
http://twitter.com/al3x
Ed Finkler
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.
--
Ed Finkler
http://funkatron.com
AIM: funka7ron
ICQ: 3922133
Skype: funka7ron
dean.j.robinson
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.
>
> --
> ICQ: 3922133
> Skype: funka7ron
>
> On Tue, May 6, 2008 at 9:25 PM, dean.j.robinson
>
dean.j.robinson
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
Ed Finkler
<Dean.J....@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.
Good for you... and also fairly sad for them.
--
Ed Finkler
Randal Hicks
Hash: SHA1
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.
Regards,
Randal Hicks
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
iEYEARECAAYFAkgh8pIACgkQHXnD0tz+/vyVnACdEcdI7P8ejlkyt0ro1Y+tXHGp
2ccAn1ieDvbgBUuqpiwPKjOkCbfw+msW
=h59J
-----END PGP SIGNATURE-----
Benjamin Tucker
I'm the guy that wrote http://stream.btucker.org/post/33710515
Sorry to miss your post on the list or I would have responded
sooner.
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:
> 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
dean.j.robinson
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
> I'm the guy that wrotehttp://stream.btucker.org/post/33710515
Benjamin Tucker
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:
Ed Finkler
>
> Hey Dean,
>
> I'm the guy that wrote http://stream.btucker.org/post/33710515
> Sorry to miss your post on the list or I would have responded
> sooner.
>
> 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).
If *any* server is rooted, the attacker can do *whatever they want.*
Stealing data out of session caches is the least of your problems.
SSL is a good idea, yes, but you should *not* be storing this data in
a cookie, period. Dean's current approach has significantly fewer
attack vectors. In addition, if the server is rooted, the attacker
will be able to pull data out of cookies just as easily as cached
session data, as it can simply be examined at the point of decryption
in the web app. No amount of SSL or app-level encryption will mitigate
this.
I'll repeat what I stated before: authentication data should *never*
be stored in cookies.
--
Ed Finkler
dean.j.robinson
session id.
The only reason the password is encrypted in the session var is
because I first tried just encrypting the cookie value, and then went
down the session path instead. Is it reasonable to assume that there
really isn't any need to encrypt if its being stored in the session
var?
On May 8, 10:58 am, "Ed Finkler" <funkat...@gmail.com> wrote:
> > I'm the guy that wrotehttp://stream.btucker.org/post/33710515
> > sooner.
>
> > 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).
>
> If *any* server is rooted, the attacker can do *whatever they want.*
> Stealing data out of session caches is the least of your problems.
>
> SSL is a good idea, yes, but you should *not* be storing this data in
> a cookie, period. Dean's current approach has significantly fewer
> attack vectors. In addition, if the server is rooted, the attacker
> will be able to pull data out of cookies just as easily as cached
> session data, as it can simply be examined at the point of decryption
> in the web app. No amount of SSL or app-level encryption will mitigate
> this.
>
> I'll repeat what I stated before: authentication data should *never*
> be stored in cookies.
>
> --
Benjamin Tucker
> > 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).
>
> If *any* server is rooted, the attacker can do *whatever they want.*
> Stealing data out of session caches is the least of your problems.
user of Hahlo I would much prefer highjacking my twitter account not
be one of them. If the credentials aren't there, they can't do that.
(unless the intrusion managed to go undetected for an extended period
of time and they altered the code.)
The point being, storing personal information (this includes account
information) is a serious liability that should not be taken lightly.
I'm actually surprised Twitter isn't more strict about this policy-
wise.
-Ben
Benjamin Tucker
If you decide to go down that route, I really think you need to
disclose to your users on the login page that you are storing their
twitter account login info.
Is there a particular reason you're not storing it encrypted in a
cookie? I'd be happy to pass along code to do this if that's the
stumbling block.
-Ben
On May 7, 10:56 pm, "dean.j.robinson" <Dean.J.Robin...@gmail.com>
wrote:
dean.j.robinson
above that I shouldn't be storing any auth details in a cookie...
The current login screen does say that the password is stored in a
cookie, and is only used to access the api. This message will be
updated accordingly when the time comes to switch over to the updated
system.
"The point being, storing personal information (this includes account
information) is a serious liability that should not be taken lightly.
I'm actually surprised Twitter isn't more strict about this policy-
wise."
cookie or session) you would currently need to re-enter it everytime
you try to access part of the api that requires auth, right? I'm
guerssing that since Quotably only has the phpsessid cookie, that it
too is using a session to hold the info.
Dean
Ed Finkler
> Sure, an attacker can do whatever they want with the server. But as a
> user of Hahlo I would much prefer highjacking my twitter account not
> be one of them. If the credentials aren't there, they can't do that.
> (unless the intrusion managed to go undetected for an extended period
> of time and they altered the code.)
How exactly do you know they aren't? you can't confirm anything that's
being done with the cookie data on the intermediary's server (in this
case, Hahlo). The data has to be decrypted and sent to Twitter by the
intermediary, and even without some kind of attacker involved, the
data could be stored or mishandled in any number of ways. You've
gained nothing by storing data in the cookie, and made the cookie a
more valuable target for XSS attacks -- which are far more common than
rooted servers.
> The point being, storing personal information (this includes account
> information) is a serious liability that should not be taken lightly.
Agreed.
Benjamin Tucker
Quotably does it in more detail.
https://quotably.com/login
The user submits a twitter username & password over SSL. The server
processes this and
then passes it along to https://twitter.com/account/verify_credentials.xml
(Note the https on the API to protect traffic from the server to
twitter)
If 200 OK is returned then the password is run though blowfish with a
secret. username & encrypted password are put into a hashtable and
then marshalled into a a base64 encoded string. The resulting string
then has a digest appended (with a delimiter) which is composed of a
sha1 hash of the marshaled data and a secret.
The results of this are then stored in the cookie.
On every request the value of the cookie gets split on the delimiter.
Then the digest (the second part of the string) is used to check the
integrity of the of the data (digest == sha1hex(data)). This protects
against modification of the cookie. Assuming this passes, the data
get unmarshalled back into a data structure. If interaction with
twitter is needed then the password is run back through blowfish and
passed along to twitter.
Features:
1) credentials are at no time passed onto the wire in the clear
2) credentials can not be stolen were there to be a XSS vulnerability
in hahlo
3) credentials can not be stolen immediately if the server is hacked
into
4) credentials can not be stolen through a vulnerability in the PHP
session store (these have happened... especially possible if it's a
shared server)
5) With the exception of a server compromise that went undetected,
there is no way a user's password can be stolen. Since it's been
shown in studies that a huge percentage of people use the same
password for multiple online services, this is a really important
point.
Limitation:
1) the session can still be hijacked, but since this is true of
twitter.com (afaik), it's not worth worrying about.
2) This doesn't help at all with CSRF vectors, but that you should be
handling elsewhere (twitter.com is good here at least when it comes to
status updates).
Does that help clear things up? Let me know if I can help at all.
-Ben
On May 7, 11:55 pm, "dean.j.robinson" <Dean.J.Robin...@gmail.com>
wrote:
Benjamin Tucker
> > Sure, an attacker can do whatever they want with the server. But as a
> > user of Hahlo I would much prefer highjacking my twitter account not
> > be one of them. If the credentials aren't there, they can't do that.
> > (unless the intrusion managed to go undetected for an extended period
> > of time and they altered the code.)
>
> How exactly do you know they aren't? you can't confirm anything that's
> being done with the cookie data on the intermediary's server (in this
> case, Hahlo). The data has to be decrypted and sent to Twitter by the
> intermediary, and even without some kind of attacker involved, the
> data could be stored or mishandled in any number of ways.
simply more risky (by many factors I would claim since it increases
the attack surfaces so greatly) to have sensitive data stored on a
server than to just have sensitive data pass through a server.
> You've gained nothing by storing data in the cookie, and made the cookie a
> more valuable target for XSS attacks -- which are far more common than
> rooted servers.
with a session id. The encrypted cookie is worthless for anything
except hijacking the session. Let me know if I'm wrong (I certainly
could be).
-Ben
Ed Finkler
> Completely true. But security is all about risk mitigation. It's
> simply more risky (by many factors I would claim since it increases
> the attack surfaces so greatly) to have sensitive data stored on a
> server than to just have sensitive data pass through a server.
Well, keep in mind that (unless overridden) the session data in PHP
has a max lifetime on the server of just a few hours, and will get
destroyed even if it is not explicitly erased. That's not failsafe, of
course, but it isn't the quite the same as a permanent store in a DB.
And, that's assuming the server-side app really is passing the data
without recording it in any way. We're still having to trust that the
Right Thing is being done, either way.
> This method is no more vulnerable to XSS attacks than having a cookie
> with a session id. The encrypted cookie is worthless for anything
> except hijacking the session. Let me know if I'm wrong (I certainly
> could be).
I think encrypted data on the client side is more problematic for a
couple reasons:
1. a session ID will expire (typically -- you can obviously set up a
non-expiring session), but the auth data in the cookie will not until
the user changes his or her password.
2. we're relying on the strength of the two-way hash as our *only*
line of defense. I don't like this because a. it assumes a lot about
the strength of the hash and the current state of technology to decode
the hash, and b. attackers have a potentially unlimited amount of time
to work on breaking the hash. My assumption is that, given enough time
and direct access, any 2-way hash can be broken. By storing the data
on the client side, we're dramatically increasing the likelyhood that
they'll have that time and access.
All that being said, I'm very reluctant to use 3rd-party web sites to
post onto Twitter (or access my gmail account, etc.) for the very
reasons we're describing.
Benjamin Tucker
> > Completely true. But security is all about risk mitigation. It's
> > simply more risky (by many factors I would claim since it increases
> > the attack surfaces so greatly) to have sensitive data stored on a
> > server than to just have sensitive data pass through a server.
>
> Well, keep in mind that (unless overridden) the session data in PHP
> has a max lifetime on the server of just a few hours, and will get
> destroyed even if it is not explicitly erased. That's not failsafe, of
> course, but it isn't the quite the same as a permanent store in a DB.
to have to be logging back in every few hours.
> And, that's assuming the server-side app really is passing the data
> without recording it in any way. We're still having to trust that the
> Right Thing is being done, either way.
> > This method is no more vulnerable to XSS attacks than having a cookie
> > with a session id. The encrypted cookie is worthless for anything
> > except hijacking the session. Let me know if I'm wrong (I certainly
> > could be).
>
> I think encrypted data on the client side is more problematic for a
> couple reasons:
>
> 1. a session ID will expire (typically -- you can obviously set up a
> non-expiring session), but the auth data in the cookie will not until
> the user changes his or her password.
as part of the marshalled data. This is used to limit the lifetime so
this isn't an issue.
> 2. we're relying on the strength of the two-way hash as our *only*
> line of defense. I don't like this because a. it assumes a lot about
> the strength of the hash and the current state of technology to decode
> the hash, and b. attackers have a potentially unlimited amount of time
> to work on breaking the hash. My assumption is that, given enough time
> and direct access, any 2-way hash can be broken. By storing the data
> on the client side, we're dramatically increasing the likelyhood that
> they'll have that time and access.
require the entire energy output of the sun to break. This is what
the military uses to encrypt stuff. I don't think we need to worry
about it. :-)
-Ben
>
> --
> Ed Finklerhttp://funkatron.com
Ed Finkler
>
> I'd assume with Hahlo this would be changed, since people don't want
> to have to be logging back in every few hours.
Yeah, that is defeated if you keep yourself logged-in. I've moved
mostly to using 1Password for that sort of thing so the login process
isn't as much of a bear, but tons of people want that feature.
> Right, what I left out of my explanation is a timestamp is also stored
> as part of the marshalled data. This is used to limit the lifetime so
> this isn't an issue.
Gotcha. That would definitely help a lot.
> Blowfish with a 197-bit key (what I'm using) has been calculated to
> require the entire energy output of the sun to break. This is what
> the military uses to encrypt stuff. I don't think we need to worry
> about it. :-)
*Probably* not. 8) I like to err on the side of paranoia in these
kinds of things, though.
In the end, the devil's in the details with things like this, and it's
easy to construct hypothetical scenarios where things go horribly
wrong, or things are very secure. A lot of my tendencies come from a
"first-party" web app background, but the use of an intermediary
service complicates the issue.
Ultimately, I think you're limited by only having HTTP Basic Auth
available. It works well for things that connect directly, but doesn't
"scale" well if you start having to pass credentials through an
intermediary. A token-passing system that generated temporary
"tickets" after a single auth check at the centralized server would
likely work better, but we go with what we have for now.
(apologies for drawing this out so long -- sometimes I get a little
more excited than I should be about things like this.)
--
Ed Finkler
Benjamin Tucker
> Ultimately, I think you're limited by only having HTTP Basic Auth
> available. It works well for things that connect directly, but doesn't
> "scale" well if you start having to pass credentials through an
> intermediary. A token-passing system that generated temporary
> "tickets" after a single auth check at the centralized server would
> likely work better, but we go with what we have for now.
feel that storing users credentials on the server is more optimal than
encrypting them and storing them in a cookie on the client?
Alex (if you're reading): does Twitter have a stance on this?
> (apologies for drawing this out so long -- sometimes I get a little
> more excited than I should be about things like this.)
-Ben
Alex Payne
clients make a best effort of maintaining the security of user
credentials, and cookie-based storage has historically not been a
great way to ensure that.
We store user passwords as BCrypt hashes in our database, and I'm
confident in that approach.
--
Alex Payne
http://twitter.com/al3x