|
Lafiel Takaaki
Registered User
Join date: 2 Oct 2007
Posts: 29
|
11-27-2007 13:27
I'm going to write a script in near future, which connects to a website. Now i'm planing to let users authentificate/register from ingame. But i'm not sure how to make the registration and authentification secure.
I already read that you can secure the parameters by submitting a MD5 hash to the page, this seems pretty easy to implement etc. I guess it would also be possible to hash the password and sent it hashed to the server, which shouldn't be a problem either.
The only problem is, how to secure the input ingame? As far as i know, the only for an avatar to communicate with an object, is "speak" to a certain channel, on which the script is listening. But that's kinda problematic, on sensitive data, as username and passwords, because any object close to the avatar, which is also listening to this channel, can be intercepted and that data isn't encrypted in anyway.
So an malicious person could put a malicious script inside the object (in which my Script is used too) in the same prim (or let it follow that avatar or sell him an item or so he attaches or just attach to yourself and flowing that person or go random around and "phishing" that data).
So i have a few questions:
1. Is there any other way, how a user can send the authorisation data to the script, which cant be intercepted by listener? (like Whisper or IM?)
2. Is there a ways to make a http_response only be triggert by the script it was called to? (At the moment, when Script A uses llHTTPRequest() and a Script B has a http_listener() too, both scripts will receive the event, and possible gather sensitive data. i.e. when a users retrives a password or receives a autogenerated password for the first time)
3. Is this any serious issue, that you have to send authentification data through unsecure ways (a channel where everyone can listen)?
Before anwsering to this questions, please take some time and read the lines below this. I also had some thoughts of how this could be solved.
Solution 1: My first tought was, to create a random channel, on which the script would listen too, everytime the object is rezzed (or change it after a fixed period of time).
Pros: - This would make it pretty hard, to intercept that communication, when the channel nummer is somewhat high (something like a random number between 100.000 and 5.000.000 or something like that). - Changes periodicly, so harder to track/guess Cons: - But it still wouldn't be "foolproof", cause there is still a little chance that someone could randomly get a listener on that, even if chances are pretty low. - It burdens the user, to have to enter a huge /23489232982 channel number
Solution 2: To have a "HUD keyboard", where user can enter the data by clicking with the mouse, to enter the data Pros: - As far as i know, this can't be intercepted Cons: - Slow way to enter the information - High effort in realizing such a hud feature - Pretty high burden to a user
Solution 3: Ignore the fact, that the channels can be intercepted and data being "fished" and use a function, to encrypt the data internally (i.e. make a MD5 Hash of the password and use the hashed value as password (which is once again hashed when stored/compared to the values on the webserver in the database))
Pros: - Easy to implement - Intercepted passwords, are useless, because they are hashed internaly (with a secret key) and sent to the webserver Cons: - Still possible to gather some sensitive data (like username), which can't be secured that way (would make it harder to manage/oversee, when you have a hashed username stored in your mysql DB)
Solution 4: Store the Authentification informations Inside the object in a notecard and read that notecard for login information
Pros: - Permanent, authorisation - User only needs to edit the notecard once and enter his data Cons: - Can be read by anyone, who has mod rights on that object (?) - http_response would still no be secure (assuming the object has mod rights, cause i wanna sell just the script to others, so they can use them in their products) and could be intercepted - it would be easily read by others scripts insde that prim (?) - if you accidently drop a copy (or give a copy) of that object to another person, your login is copied too (cause it was stored permanently into the object)
Solution 5: Similar to #4, but you don't store the notecard permanently in the object. Instead, the user (who fishes to authentificate) drops his notecard (with his login/password in it) on to the (inside) the object (which is either rezzed on ground or attached (can you drag items into attached objects?)). The script reads the file, once it was droped (inventory updated/changed event?), read the login and deletes the notecard and starting a session (which is valid for a certain amount of time only for that certain user)
Pros: - Easy temporary session authentification - Doesn't depend on "channels", which can be intercepted - Works without direkt user input (i.e. writing into the chat textbox), just by drag n droping the notecard Cons: - Only usefull on objects you own (do you need mod permissiosn, to put items into other items)? - Can other put their scripts into objects you own? (Not sure it that works, haven't ever tested)
Solution 6: Safe the login information into object description (or let the user enter it that way) Pros: - Easy implementation - Can't be intercepted (as Attachment) Cons: - Would only be usefull for HUD attachments (Can HUD attachment be seen by others in any way? (either by looking, Inspectig or even analyzing the traffic (from other person/attackers viewer (client) ??)) - When rezzed on ground, high risk of sensitive data leakage (well, descriptions could be reseted on rez i guess) - Mod permissions needed (confirmation??) - Not the most secure way of authentification (think it's not really fool proof)
As for some of the solutions i tought about, i'm not completly sure if they can be realized that way. For example, i don't know yet, how this behaves on different objects with different permissions (for example if Your Objects can be intercepted by putting a script into a terminal Like object, to intercept authentifications by notecards or if people can put items if nomod rights are set). It's more like brainstorming, about possible ways to implement something, so i haven't done more accurate researchs on the techniques and their possible (or impossible) implementation.
Maybe some other scripters here, have had similar problems, when they tried to secure the sensitive data transmission between user and script/website and can post their solutions or suggest which one of the above one is good (with pro and cons) or maybe come with another solution/sugestion, which mixes some of the above (or even with new) ideas.
P.S. Writing this, i'd tend to like the notecard idea, which is somewhat like a identity/credit card like.
|
|
RJ Source
Green Sky Labs
Join date: 10 Jan 2007
Posts: 272
|
11-27-2007 16:13
If you are very worried about the user creating a password in game, you might consider generating the password from your script or web server, and telling (IM, email, etc) that password to the user. If you use email, it would double as a way to verify the user has given you the correct email address.
Then later they could change it if they wanted. Maybe thru the web site and https rather than in game.
Rj
|
|
Lafiel Takaaki
Registered User
Join date: 2 Oct 2007
Posts: 29
|
11-27-2007 18:12
From: RJ Source If you are very worried about the user creating a password in game, you might consider generating the password from your script or web server, and telling (IM, email, etc) that password to the user. If you use email, it would double as a way to verify the user has given you the correct email address. It's not just the "creating" of the password, which is problematic, but every time when they are requested to authentificate, they have to enter their login information. And while they enter, there is a chance, that it could be intercepted (i.e. an object next to them, listening on one or more channels). It's that imporant, because this project is all about lindes (aka money). So if someone would be able to get someones login, he could be able to take his money (not just items for free). I know that a simple identification could be done, by using the UUID of the owner, but... ... i want, that not only the person has access to it, but that the ressources could be shared with a group of people (i.e. 2 or 3 friends) ... to relay only on owners UUIDs isn't that good thing, cause basicly everyone (who knows the address which is being used to comunicate with the webbrowser), could probably fake this, by making a script, which calls that url with someone others UUID Let's say, there is one terminal around (not an HUD object) and some malicious person, with an listener scripts, stays close to one of the terminals, trying to intercept the user authentification, by listening to a few (maybe a few 100 or 1000 channels) and by luck gets the right channel, he could see what the user has said in that channel (i.e. /5349 auth username password). Now he could use this, to authentificate once the user is gone and had access to his account. That's what i try to prevent and thinking of a good way to prevent such things, before i actually start writing the script itself. A more direct question would be: How high is the risk of such an situation? Maybe i'm bit to paranoid (and too focused on the security) about such things and try to make it absolutly fool proof, that it holds me off from actuall scripting  My goal is, to make it as secure as possible for my customers. A bad security leak, could easily ruin your reputation/project/businies and that's the last thing, i want to happen. (My motto would be like: Better overdo it with security, than regret it later  )
|
|
Xhawkx Holden
Registered User
Join date: 1 Nov 2006
Posts: 86
|
11-27-2007 19:33
Just a few thoughts.....
You store the UUID of a target AV, and then could give the AV an object in world, that could be either worn as an object (like a security card), or attached as a hud. Then when the AV was say "in range" to another object of yours, it could sense the worn object, and detect the owners UUID. This can't be mimicked anyway that I know of. If the AV needs a password to access an external site, you could generate the password, and then have the script IM to the AV the password that has been generated for him.
This would then have two seperate authentication schemes... One for external websites (the generated password), and one for in game (the UUID).
You could allow for the user to log into the website and change the password to a password of their choice.
|
|
Void Singer
Int vSelf = Sing(void);
Join date: 24 Sep 2005
Posts: 6,973
|
11-27-2007 21:57
you already have everything you need to uniquely identify an av... their key, in the touch_start event... people can know it but knowing does them no good w/out access to the account... add a pw and you've covered almost every angle possible
_____________________
| | . "Cat-Like Typing Detected" | . This post may contain errors in logic, spelling, and | . grammar known to the SL populace to cause confusion | | - Please Use PHP tags when posting scripts/code, Thanks. | - Can't See PHP or URL Tags Correctly? Check Out This Link... | - 
|
|
Lafiel Takaaki
Registered User
Join date: 2 Oct 2007
Posts: 29
|
11-28-2007 07:03
From: Void Singer you already have everything you need to uniquely identify an av... their key, in the touch_start event... people can know it but knowing does them no good w/out access to the account... add a pw and you've covered almost every angle possible Well, but this wouldn't allow, that 2 or more people could share/access this account. Let imagine, 3 friends wanna run a project and need to share their ressources (Money, maybe even (transfer/nocopy) items), but they don't wanna share their SL Account (cause there are risks, that they take more than they're allowed to and it's against ToS afaik to share account related data). So that account shouldn't be bound on the avatar, but on the accountname (you choose, when you register). Should work similar to a bank (you got your account number (or card) and a PIN to access it at terminals).
|
|
Yumi Murakami
DoIt!AttachTheEarOfACat!
Join date: 27 Sep 2005
Posts: 6,860
|
11-28-2007 07:06
From: Lafiel Takaaki Well, but this wouldn't allow, that 2 or more people could share/access this account. Let imagine, 3 friends wanna run a project and need to share their ressources (Money, maybe even (transfer/nocopy) items), but they don't wanna share their SL Account (cause there are risks, that they take more than they're allowed to and it's against ToS afaik to share account related data). So that account shouldn't be bound on the avatar, but on the accountname (you choose, when you register). Should work similar to a bank (you got your account number (or card) and a PIN to access it at terminals). 1. Have the users log in to a web site, give their avatar's name on the web site, then touch a terminal to associate their key with an account. Several avatars can associate with one account if they want to. 2. Give the user a HUD object which is no transfer. Have them enter their username and password in the "description" field of the object. Since there is no way for anyone else to click on a HUD, they won't be able to read it (but beware of the user accidentally attaching the HUD to the wrong place; also, it MAY be possible to get the key of the HUD and read the description via script)
|
|
Void Singer
Int vSelf = Sing(void);
Join date: 24 Sep 2005
Posts: 6,973
|
11-28-2007 08:25
From: Lafiel Takaaki Well, but this wouldn't allow, that 2 or more people could share/access this account. Let imagine, 3 friends wanna run a project and need to share their ressources (Money, maybe even (transfer/nocopy) items), but they don't wanna share their SL Account (cause there are risks, that they take more than they're allowed to and it's against ToS afaik to share account related data). So that account shouldn't be bound on the avatar, but on the accountname (you choose, when you register). Should work similar to a bank (you got your account number (or card) and a PIN to access it at terminals). allow them to add an avatar to the account... of course the fact that you are considering multiple people will access the same account, means the account is already unsecure at a basic level... but at that point it's the base users problem... out of world you would still use account/pin type security, but it isn't neccessary inworld, as you can just associate multiple av keys with the account...
_____________________
| | . "Cat-Like Typing Detected" | . This post may contain errors in logic, spelling, and | . grammar known to the SL populace to cause confusion | | - Please Use PHP tags when posting scripts/code, Thanks. | - Can't See PHP or URL Tags Correctly? Check Out This Link... | - 
|