Pandora Apps Some Thoughts ....

[Christoph.Krn]

cloudef ok ill look at this simple method tomorrow.

Don't implement it that way -- it allows for replay attacks and is very dangerous.

 

[Cloudef]

cloudef ok ill look at this simple method tomorrow.

Don't implement it that way -- it allows for replay attacks and is very dangerous.

Yeah indeed, that system straight like that would be prone to capturing the hash and resending it.


You can smaller the risk by doing repo.openpandora.org/login page where these credentials are given once.


And then you are given session ID that you use to fill the rest API calls that need login.


However, this can be spoofed too but the risk is much smaller than going straightforward way.


There is also OAuth protocol, but it is pretty PITA for clients to use.


Though the OAuth method might be the way to go.


Edit:


Also I suggest not allowing clients to send username and password information.


Instead tell them to log into repo page first time and generate Client/API key there first which will be unique to that user, and clients use that instead.

 

[Eight Bit]

Back on topic: Maybe something simple like a 'featured app list' that someone maintains would be nice?

 

[Tempel]

I once suggested using digest access authentication, as it is an existing standard and has some reasonable security against passive attackers (though it won't stop a man-in-the-middle). Milkshake said he'd look into it, then never followed up .

 

[Cloudef]

@Tempel


We decided on something like this for now: https://github.com/Cloudef/libpndman/blob/repo_api/lib/repo_api.c


Still quick and dirty code, I should clean up libpndman a bit after this feature is done.


I don't like the idea of having too many different interfaces however.


We already have JSON, PXML and now the repo user api. The specs will be in wiki I guess after milkshake_ implents this fully.


Libpndman will probably store user's username and API key if provided in the database file for each repository he provides one.


So you can do voting and other things for those repositories you have provided the key and username. Password is never needed, and you won't have full access.


If API key is ever stolen, you can login to repo and regenerate it.

 

[Tempel]

First, a repo API really is part of the repo specification. The whole JSON bit can communicate package information, but more complex interactions are an important extension to that. At the very least, users need to be able to log in so they can access PNDs that other users may not be allowed to access (eg: purchased apps). And at that point, it seems sensible to work in commenting and rating from the client. Of course, any piece of this is optional for any given repo implementation.


Second, what is this about API keys? A user must log in to the repo, request the key, then give that key to the client, correct? That seems unnecessarily cumbersome when we already have secret passwords. And though I don't quite follow your code, it looks similar to digest authentication, but uses a client-generated nonce instead of a server-generated one. So I still think digest authentication is a better idea, as it's a long-standing standard. But you're the new master of repo clients, so it's ultimately up to you . Consider it.

 

[Cloudef]

Second, what is this about API keys? A user must log in to the repo, request the key, then give that key to the client, correct? That seems unnecessarily cumbersome when we already have secret passwords. And though I don't quite follow your code, it looks similar to digest authentication, but uses a client-generated nonce instead of a server-generated one. So I still think digest authentication is a better idea, as it's a long-standing standard. But you're the new master of repo clients, so it's ultimately up to you . Consider it.

I don't really like storing user's passwords anywhere even encrypted. The API key's solve this nicely and it won't especially be problem if there is even going to be multiple repos. Those repos just work which user has provided api key and is never prompted again (unless API key is generated again.), There is tool included which will allow you to login to repo and generate key from CLI without browser if that is issue.


About the digest authentication, it might be overkill as breaking the API access won't give you full access to the user's account anyways. And this method is already fairly secure, heck it's more secure than browser's authentication to repository right now.

 

[Christoph.Krn]

About the digest authentication, it might be overkill as breaking the API access won't give you full access to the user's account anyways. And this method is already fairly secure, heck it's more secure than browser's authentication to repository right now.

Tempel is right, ultimately it's up to you, but I must strongly oppose this reasoning. The way I see it, if the security of something is screwed up, then it's broke.

If you want to do it this way, you need not save the user's password if you only use it to authenticate her once so as to negotiate the API key.

 

[Cloudef]

If you want to do it this way, you need not save the user's password if you only use it to authenticate her once so as to negotiate the API key.

The password is never asked. You generate the key on repo page, or optionally using third party script included in milkyhelper that does this for you. That stores nothing. The current security method is not done by me alone, it's milkshake who originally suggested it to me. I don't see any problem with it either.


But this isn't up to me, I'm not deciding the standards here. Milkshake's currently the one who has the 'main' repository and he pretty much holds the cards here, if you wan't different authentication method you can go suggest it to him and I'll follow behind.

 

[Tempel]

I don't really like storing user's passwords anywhere even encrypted.

Even hashed, as allowed for by digest authentication? Security is about leveraging secrets; the password is already secret, so leverage it some more. Making users manage API keys is just a hassle when they don't need to. Also, I like repeating: existing standard.

But this isn't up to me, I'm not deciding the standards here. Milkshake's currently the one who has the 'main' repository and he pretty much holds the cards here, if you wan't different authentication method you can go suggest it to him and I'll follow behind.

I was kind of hoping he'd be reading this. Maybe direct him to these comments.

More importantly, it takes two to tango. Both of you need to buy in to make this system work. For that matter, this is a community-defined specification. Milkshake doesn't own it any more than the rest of us. And it's up to all of us to create a specification that makes sense no matter who implements it.

 

[Cloudef]

Even hashed, as allowed for by digest authentication?

Yes, call me paranoid, on that part.

Security is about leveraging secrets; the password is already secret, so leverage it some more. Making users manage API keys is just a hassle when they don't need to. Also, I like repeating: existing standard.

Yeah, I suggested OAuth for milkshake_, but I guess it was too much.

More importantly, it takes two to tango. Both of you need to buy in to make this system work. For that matter, this is a community-defined specification. Milkshake doesn't own it any more than the rest of us. And it's up to all of us to create a specification that makes sense no matter who implements it.

I'm more of the type who can suggest something, but ultimately leaves the decision to others and follows with it. I'm not really security expert nor design person by any means.

 

[milkshake]

And though I don't quite follow your code, it looks similar to digest authentication, but uses a client-generated nonce instead of a server-generated one. So I still think digest authentication is a better idea, as it's a long-standing standard. But you're the new master of repo clients, so it's ultimately up to you . Consider it.

there is a client nonce and a server generated nonce not just a client one.


you are right this is a community thing so feel free to help us decide how it should be done, this is using the digest method (though not in the digest standard me thinks).


this is how the handshake works so far:

//---------> through POST method client sends request for handshake by POST param stage=1


//<--------- the client generates a new session (which lasts only 15 seconds), generates a

random 12 digit NONCE sequance and returns this value to the client.


//---------> once the client has this NONCE it generates its own client NONCE and POSTs

this back to the server along with the username of the user and a special md5 hash

which works like this md5(NONCE+CNONCE+APIKEY). So the following gets posted

back to the server:

stage=2&user=<username>&hash=md5(NONCE+CNONCE+APIKEY)


//<--------- as long as the session on the server is still active, the server pulls up the

users APIKEY from the db and replicates the client submitted HASH for validation i.e.

md5(NONCE+CNONCE+APIKEY), the server then checks both hashes against each

other (client hash and server hash) and if they match we allow an action, after which

the session is destroyed again.


//if there are any errors in the POST or missing required params the session is

destroyed and the handshake needs to start again.

an API key was decided because some people might not trust the client with the password details (maybe after the potential security issue with streaks app), this is easily generated and does not require the user to manually log into the website as zloud has wrote a script that will allow one to be generated from (the terminal? or the client maybe).


but if peope decide againsts the API key thing it can be deleted though I kinda like it, maybe its overkill but its secure at least.

 

[Tempel]

On second thought, the API key isn't a bad idea. It's effectively just a password that can be used only through client software. And any repo that implements it could choose the API key to be the same as the user's usual password. Heck, if users complain about the API key, you could choose to set it as their passwords any time in the future. So let's leave it as a distinct key for now, knowing that the usual password could be implemented as that key.


Again, the method you guys have rolled seems quite similar to digest authentication, so I still think you should look at it. But digest authentication relies on sending nonces, usernames, and hashes through HTTP headers. To clarify, are you sending the information through an HTTP POST command, or are you sending it in the URL parameters of a GET command? I've done most of the repo spec wiki page updates so far, so I figure I'll add this in once it's finalized, so I want to make sure I fully understand it.

 

[milkshake]

yes this info is sent through HTTP POST command.


this method follows the same path as DIGEST only its not implemented through the headers.

 

[Fzero]

This topic is a bit out my depth, interesting, but I don't know so much about this. I just found out what all this nonce talk was about, number used once. It was bugging me reading about security sex pests, I knew that didn't make sense.

 

[porg]

I take my review duty serious at repo.openpandora.org


167 comment appearances at the moment, according to Google.

 

[diligentcircle]

I take my review duty serious at repo.openpandora.net

Check your spelling. Going to openpandora.net leads here.

 

[Prometheus]

^ Ooh, that's not very good...

Something for the OpenPandora Team to deal with?

 

[porg]

Thanks for correcting my typo.


At least we now know that there is a domain name competitor...