Why not allow API calls with the login uname and pwd? why only using api key? Makes it harder to write apps that act on behalf of a user.
2 years, 2 months ago.
22 comments so far
The API key is going away at some point and a app-key based system is coming in (like Flickr's) .. getting a user's password is never a good idea. The system generated API key is a touch more secure (who knows where else they may have used the password?)
The simpler any security system is, the more insecure it is.
As I said, by using someone's real username and password you open them up to a lot of security risk in other places that they may have (insecurely) used the same u/p elsewhere.
There's also the thing that if they give you their username and password, you can access things at Jaiku not available via the API (which you currently can do, but we keep being told will be closed as it should be)
In any good API (e.g. Google Accounts) you have a seperation between what you can on your account, what one can do with the API on one's account, and what one can do with the API on behalf of another's account. I agree with your comment, only ask why the API key, when not every user knows their API key? How can I write an app that performs actions on behalf of a user?
There are a lot of third-party apps out there .. so obviously not many people are having trouble with it :-D http://jaiku.com/api/key is the link you want to give your potential users
Using the username and password would be absolutely horrid considering that the Jaiku API is accessed via plaintext. No offense, but with the current lack of SSL at Jaiku.com, I honestly can't think of a dumber idea. If they went that route, there is no way I'd ever use the API.
Even the API key is easily captured and then anyone can forge access to your account. But at least they don't know your actual password, so they can't completely take over your account, as they need your current password to change your password.
Now, I understand that the Jaiku folk don't really want to have every API connection be SSL wrapped, as that would be a massive performance hit. What I'd suggest is using an SSL connection to the API wherein the user's name and password are sent, and a randomly generated session key is then returned. This session key would have a lifetime on it of say half an hour. This session key would then be used much in the manner that the current API key is used. This way, you'd have the benefit of SSL for the actual password exchange, without completely overloading the server. Someone could still capture their current session key, but at least the window of impersonation would be limited to a half hour at maximum.
To simplify things for client writers, the API should then add a new error result for "session key expired". Then the client's logic would look like this:
1) Start client, request first session key
2) Use session key until "expired" result returned
3) Request new session key
4) Go back to step 2
This way, the client doesn't actually have to know what the expiration time is, allowing Jaiku to tweak it up or down on the server side as they desire. Also, if the client goes to "sleep" for a while, it won't have to worry about a timer waking it up to fetch a new session key when it may not need one again for some time. That is, it won't have to request a new session key until it really needs a new session key.
Ideally, there would be an API server that used SSL for everything. But given the connectionless nature of the Jaiku API, that would require them to use SSL accelerator equipment or watch the website fall over and die from the encryption load.
CAW, Once again, keep the scenario in mind. The use case is the same as in a Twitter API call or a Google Accounts Auth. The user AGREES to let the app login to Jaiku. From security standpoint, having the user provide a userName + api key, is no different then having the user provide a userName + password. In both cases, it requires that the user provides the creds, just in the API key case, the user must know that there is an API key (wierd).
I suggest that Jaiku takes the Google route (AuthSubToken) or the Facebook route, either way the current solution is nothing to write home about.
The flickr-type auth is almost complete to the point where they just need to write the docs and get it tested. There won't be any other auth once that's been in place long enough that they can turn off the API-key. From where I sit, the API key was always a more-secure-than-sharing-your-password approach until the full auth system could be put in place. (The flickr system is fairly similar to the Facebook system)
And again, sending the user's real password in every API transaction as plaintext is absolutely rediculous to suggest. It will be sniffed and compromised in no time.
The only way this would be remotely acceptable is if the API connection was persistent. But as it is now, a new TCP connection is used for every transaction.
for the record, we're likely to be using oauth as the auth system (though as you said the flickr auth is complete so perhaps we will support that also) which is quite like the flickr system and we will probably keep the username + personal key system for a while because it is easy to use internally.
This discussion is fascinating. Lots of the same things we've been going over for the past 8 months or so on the OAuth planning/design list. In any case, @termie has been working on the spec with us and I think that it's going to answer all the needs presented here.
As with Twitter, there will need to be a transitional period but it will be a much better situation in the end than using cleartext.
I had no intention to get everyone into a heated debate. On my end, I am only trying to create an app that will be as intuitive as possible to the user. Anyhow, I will work out something and wait for updates on this thread. Less worried about someone sniffing uname and pwd, but any Auth flow (supported by a proper partner certification program) would be greatly appreciated. Let me know what I can do to help.
If you're interested in OAuth you read the spec as it progresses or apply to join our mailing list (which should be opened up sometime in October). Great to see this discussion happen.
22 comments so far
The API key is going away at some point and a app-key based system is coming in (like Flickr's) .. getting a user's password is never a good idea. The system generated API key is a touch more secure (who knows where else they may have used the password?)
2 years, 2 months ago by RickMeasham
but u can change your pass, but cant change your key.
there should be a page (maybe linked on the API page) that shows the pages/apps that are safe to insert the key
2 years, 2 months ago by BUGabundo
To change your key just change your password to the same as it currently is. That will cause the engine to regenerate your key.
2 years, 2 months ago by RickMeasham
I can't remember, but you may have to change it to something else first then change it back to the password you want :-D
2 years, 2 months ago by RickMeasham
Yuck, I think the cleanst would be to just use the uname and pwd like in Twitter or GTalk. No?
2 years, 2 months ago by slehavi
Clean?? Clean == Simple
The simpler any security system is, the more insecure it is.
As I said, by using someone's real username and password you open them up to a lot of security risk in other places that they may have (insecurely) used the same u/p elsewhere.
There's also the thing that if they give you their username and password, you can access things at Jaiku not available via the API (which you currently can do, but we keep being told will be closed as it should be)
2 years, 2 months ago by RickMeasham
In any good API (e.g. Google Accounts) you have a seperation between what you can on your account, what one can do with the API on one's account, and what one can do with the API on behalf of another's account. I agree with your comment, only ask why the API key, when not every user knows their API key? How can I write an app that performs actions on behalf of a user?
2 years, 2 months ago by slehavi
do as every app out there: place a link to the user api key. when a user uses your app, along with his jaiku username, they get also get the api key
2 years, 2 months ago by BUGabundo
There are a lot of third-party apps out there .. so obviously not many people are having trouble with it :-D http://jaiku.com/api/key is the link you want to give your potential users
2 years, 2 months ago by RickMeasham
Using the username and password would be absolutely horrid considering that the Jaiku API is accessed via plaintext. No offense, but with the current lack of SSL at Jaiku.com, I honestly can't think of a dumber idea. If they went that route, there is no way I'd ever use the API.
Even the API key is easily captured and then anyone can forge access to your account. But at least they don't know your actual password, so they can't completely take over your account, as they need your current password to change your password.
Now, I understand that the Jaiku folk don't really want to have every API connection be SSL wrapped, as that would be a massive performance hit. What I'd suggest is using an SSL connection to the API wherein the user's name and password are sent, and a randomly generated session key is then returned. This session key would have a lifetime on it of say half an hour. This session key would then be used much in the manner that the current API key is used. This way, you'd have the benefit of SSL for the actual password exchange, without completely overloading the server. Someone could still capture their current session key, but at least the window of impersonation would be limited to a half hour at maximum.
To simplify things for client writers, the API should then add a new error result for "session key expired". Then the client's logic would look like this:
1) Start client, request first session key 2) Use session key until "expired" result returned 3) Request new session key 4) Go back to step 2
This way, the client doesn't actually have to know what the expiration time is, allowing Jaiku to tweak it up or down on the server side as they desire. Also, if the client goes to "sleep" for a while, it won't have to worry about a timer waking it up to fetch a new session key when it may not need one again for some time. That is, it won't have to request a new session key until it really needs a new session key.
Ideally, there would be an API server that used SSL for everything. But given the connectionless nature of the Jaiku API, that would require them to use SSL accelerator equipment or watch the website fall over and die from the encryption load.
2 years, 2 months ago by CAW
CAW, Once again, keep the scenario in mind. The use case is the same as in a Twitter API call or a Google Accounts Auth. The user AGREES to let the app login to Jaiku. From security standpoint, having the user provide a userName + api key, is no different then having the user provide a userName + password. In both cases, it requires that the user provides the creds, just in the API key case, the user must know that there is an API key (wierd). I suggest that Jaiku takes the Google route (AuthSubToken) or the Facebook route, either way the current solution is nothing to write home about.
2 years, 2 months ago by slehavi
The flickr-type auth is almost complete to the point where they just need to write the docs and get it tested. There won't be any other auth once that's been in place long enough that they can turn off the API-key. From where I sit, the API key was always a more-secure-than-sharing-your-password approach until the full auth system could be put in place. (The flickr system is fairly similar to the Facebook system)
2 years, 2 months ago by RickMeasham
i alreay asked for SSL on #wishku. troubles me to login without it. cant get why they dont set one up.
2 years, 2 months ago by BUGabundo
And again, sending the user's real password in every API transaction as plaintext is absolutely rediculous to suggest. It will be sniffed and compromised in no time.
The only way this would be remotely acceptable is if the API connection was persistent. But as it is now, a new TCP connection is used for every transaction.
2 years, 2 months ago by CAW
for the record, we're likely to be using oauth as the auth system (though as you said the flickr auth is complete so perhaps we will support that also) which is quite like the flickr system and we will probably keep the username + personal key system for a while because it is easy to use internally.
2 years, 2 months ago by termie
Got a link that describes "oauth" in more detail?
2 years, 2 months ago by CAW
What happened when you googled it? Maybe your googlefu isn't as good as mine? Nah, you just didn't put in any effort!
2 years, 2 months ago by RickMeasham
This discussion is fascinating. Lots of the same things we've been going over for the past 8 months or so on the OAuth planning/design list. In any case, @termie has been working on the spec with us and I think that it's going to answer all the needs presented here.
As with Twitter, there will need to be a transitional period but it will be a much better situation in the end than using cleartext.
2 years, 2 months ago by factoryjoe
/me triggers chris's search words
2 years, 2 months ago by termie
I had no intention to get everyone into a heated debate. On my end, I am only trying to create an app that will be as intuitive as possible to the user. Anyhow, I will work out something and wait for updates on this thread. Less worried about someone sniffing uname and pwd, but any Auth flow (supported by a proper partner certification program) would be greatly appreciated. Let me know what I can do to help.
2 years, 2 months ago by slehavi
If you're interested in OAuth you read the spec as it progresses or apply to join our mailing list (which should be opened up sometime in October). Great to see this discussion happen.
2 years, 2 months ago by factoryjoe
Sounds good, spec looks fine and I have added myself to the mailing list.
2 years, 2 months ago by slehavi