Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

The problem:

I have an open-source client (a Firefox add-on written in JavaScript) and a server containing somewhat sensible user information: username and user history (all from YouTube). The client is able to add new entries to history and to query full history (by telling his username). The communication is on HTTP protocol. The problem is that, there's no passkey or any authentication. This means than anyone can fake to be somebody, by creating fake HTTP requests, with modified GET data, and retrieve a full history of another user.

How can I generate a password (or hash), that can't be guessed, but it can be used to authenticate the client?

Possible solutions (or what have I thought / tried already)

1. Create a registration system for this service

I could add a registration form and a login form, and associate service user with YouTube user with some kind of verification, but that's too much hassle for the user. It's really just a basic service so this would be an overkill.

2. Make it closed source

Firefox add-ons are not necessarily open sourced. By making it closed sourced, I could do a simple trick like creating a costum hashing function (or just simply a costum salt for the hash) which is hidden by the closed source. This way I would generate a password direclty from the username. There are two options here:

a.) Create it as a C++ XPCOM component. I tried that. But turns out, this is also an overkill. It's very incompatible across gecko versions and I haven't even got to compile it across platforms. It's really hard to debug, there's almost no support at all and most importantly: I don't like the idea of maintaining a binary piece compiled for every version of Firefox for every platform just to have 5 line of code encapsulated in a 300 line interface. Also, what if I decide to port this add-on for Chrome? There's no such thing as XP-COM.

b.) Make it an obfuscated JavaScript. I don't know how to write JS code that is hard to decipher. It's also much easier to just copy paste the obfuscated code, change the initial parameter and have the hash for the desired username. With the XPCOM component is so hard to work, thus isolate and run it with false username, that I almost consider that as acceptable security :D.

3.) Get password from YouTube

If I could get a code from YouTube, just as easily I am getting the username (get a dummy page in background and fetch the username from source code) I would be saved. But I can't. There's no way I could get the real password, maybe if it's saved I could get that way, but I can't base on that. Well, I don't need the real password anyway, anythings fine as long as it's a secret, it's unique to user and constant by user (every user has one and only one, available anytime).

a.) I searched YouTube's source code and the embedded player's parameters and found something, but wasn't secret. It was somewhere in the profile, and I could see other user's codes. So this means: I found nothing.

b.) I also checked the cookies. But after a re-log-in there was no cookie value that haven't changed it's value. Not that I could understand what cookie does what.

Overview

The problem with all these are that... they are so unprofessional. I posted this question in hope of some cool method invented for scenarios like this. A handshake or something.

I need this because I have to write a Terms of service for my add-on. And I can't just write inside that I'm saving your history to an external server for the benefit that you can use my add-on across many computers without any security, That anyone who downloads Fiddler, and knows what HTTP protocol is can simply view what videos have you watched.

Sorry for the question being so long, and sorry if it's off topic (I hope it's not).

share|improve this question
add comment

1 Answer

up vote 3 down vote accepted

There's no way to implement this in such a way that it is manageable and has effective security. That you have to use HTTP (and therefore not HTTPS) makes it very, very difficult to protect the system against MITM / replay attacks. Generating a hash determinisitically from the username directly does not really help - it doesn't solve the MITM problem and exposes the system to brute force attacks.

You could just generate a random value, store it in a long lasting cookie and use it as a session identifier (effectively a password surrogate) matching it to a username on first access - this will still be vulnerable to XSS and MITM - but then you've got the additional problem of how you reset the users password.

You can't get the youtube account password from the youtube - but you can get it from the user along with the youtube username and test it for validity.

I think you could do a lot worse than what is done here - using a long lasting session id, authenticated against openid or a application specific service. (But do bear in mind that this is not totally secure).

share|improve this answer
    
How would https improve on this problem? Because I don't see anything https can offer that would lessen the risk (except MITM I don't care about). Also I'm not willing to implement a foolproof security (image download blockers are far from being foolproof, yet they are still considered security). The thing is, I can't have a no-security scenario either. I'd like to get the maximum I could get from whats given. I don't want to secure against MITM, I just want to distinguish valid requests coming from the add-on by those builded manually (I think thats what is called replay attack). –  SinistraD Apr 2 '12 at 18:43
    
I'm not getting the username from the user, I'm fetching it from the website. The session is a good idea, but how can I create it? (I don't understand this: "matching it to a username on first access"). Getting the password from user sounds like the best solution so far, but I think it's a bit hard to verify that. It's also really troublesome for both me (implementing) and the users (using it). And finally, if it's openid it might as well be the youtube api, but I cant see how could I use that either (it's a client not a website). An application specific sercie sounds good, but is there any? –  SinistraD Apr 2 '12 at 19:15
    
I accept this as solution, as a "there's no way to do it". I found something tho (but I really had a big luck, and it's really situation specific solution), so I think I'll manage. Anyway, thanks for the help. –  SinistraD Apr 6 '12 at 1:44
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.