related to
child of
duplicate of
 |
Hmm, what would work, and fit into my plans, would be a really basic, no frills, HTML forms based account management web page built into OpenSim_SC. |
|
|
opensim-SC/OpenSim/Framework/Console/RemoteConsole.cs is an example of authenticating a user. |
|
|
A simple CRUD system. Using the new MySQLRaw.cs, don't bother making versions for other databases, this will likely only be used by a few grids that should stick to MariaDB / MySQL. Confirmed that CG, IG, and MG all use MariaDB. Have a table structure, filled with field structures. A row structure will point to it, and include actual row data. Also some top level databaseData structure that would include several rows, and be the thing that is edited. The databaseData should include copies of the original data, so it can deal with the lost update problem. |
|
|
The list button should list all members, first and last names. White for approved members, grey for disabled members, blue for gods. If the logged in member is a god, they can click on a name to edit that member. Just basic email, password, and approved / disabled / god status editing. A logged in member can edit their own email and password. |
|
|
Looks scary. And they are both now irrelevant, I've switched to C + Lua, the C# .NET stuff is now legacy. |
|
|
Block creating accounts with the god first names, surnames, and full names, those can be done in the console. |
|
|
Replace first/last name with a single name field, then check if it's two words server side. A great anti spammer thing I have found. |
|
|
Use the manual DNS method of certbot, and use one of the domains from afraid. Or temporarily use sledjhamr, the webroot method as usual, then copy things. Now irrelevant, I've switched to C + Lua, the C# .NET stuff is now legacy. |
|
|
https://stackoverflow.com/questions/7400500/how-to-get-private-key-from-pem-file https://www.codeproject.com/Articles/162194/Certificates-to-DB-and-Back Now irrelevant, I've switched to C + Lua, the C# .NET stuff is now legacy. |
|
|
Now irrelevant, I've switched to C + Lua, the C# .NET stuff is now legacy. |
|
|
config/config.ini is shared with sims, and they can't all use the same port. config/ROBUST/RobustExtra.ini didn't work, not even if including it. No idea why. Figured out why, it has to be at the end. Now irrelevant, I've switched to C + Lua, the C# .NET stuff is now legacy. |
|
|
Authentication and sessions. Force SSL. Two word name in a single edit box. Password in a password box. Create a token, pass it around. Token expires, and is "only from IP xxx.xxx.xxx.xxx". Token is in header, cookie, or both. Both, and compare them to validate them. The token should be non-predictable. Hash the token like you would the password before storing it server side. Regenerate the cookie when the user is authenticated. Another possibility, split the token into two bits somehow, likely cryptographically, one in the header, the other in the cookie, then when recombined they must match something or other stored server side. HttpOnly, Secure, Session, SameSite=Strict, Path=/web cookie. Check the referer header is us. Logout and password resets should invalidate the token. Password reset and validation email could be the same process? Re-use the hashed cookie stuff? DoS protection against dictionary attacks - increasing delay type stuff, let the user know what's going on. All sorts of other things, but I think this is enough for the simple account manager. Very useful. Covers a specific detail about cookies. Session fixation attack. Mozilla's docs on cookies. |
|
|
I should use prepared SQL statements. |
|
|
Add a validation field, and a "resend validation email" button. |
|
|
I've decided to not include the account manager stuff I have been working on in this release of OpenSim_SC (0.9.0.1). I was using the built in OpenSim web server. Something they wrote themselves, but that they didn't include the source code for it in the OpenSim source repo. I managed to track down the source code, but dunno if it's the same version as the binary they include. It's not designed for ordinary web pages, but rather as the internal communications between modules, and the viewer parts that run over HTTP. It has support for HTTPS, but that's a rarely used option. Turning it on so I can use it to protect account management resulted in lengthy error messages. They happen when people are not using the account manager. So I'm very worried that I am triggering not well tested code paths. The current OpenSim_SC release candidate has been well tested, and I think it is ready for release soon, but not with HTTPS enabled causing new problems. I planned to switch to lighttpd eventually anyway, even for the internal stuff. I think I'll work on using that for account management after this release. Lighttpd is about a third of the size of OpenSim web server, and heavily used by lots of people, being one of the top three open source web servers. Built to be light on resources and fast. It's a real web server, OpenSims isn't. MG already has a Joomla based account system, IG has something similar based on Drupal, we will just have to wait a bit longer for my implementation. |
|
|
Add a MOTD when people log on, and allow to randomly pick it from a pool of MOTDs. This feature requested by Taylor. |
|
|
Feature request: Make partnering work via the accounts system. |
|
|
User must provide the old password when changing the password. So that "someone used my existing session to change my password" wont work. |
|
|
Provide an option to use ssh keys or similar. |
|
|
fido technotes channel binding and fido might be useful, though could be more or less what I came up with elsewhere, split token. |
|
|
2019 CWE Top 25 Most Dangerous Software Errors will be useful. |
|
|
Should get this web stuff to work on MOAP, and check if that works as a HUD. Dynamic texture stuff likely wont work, I don't think text edit widgets are supported. MOAP worked as a HUD, I was able to use Candy and chat in the IG chat room. |
|
|
I'd love to move on from the current OpenSim password hashing, to something more modern and more secure. And then in a decades time update it once more. The problem will be knowing which one to try, coz there will be old password hashes until old accounts can update. I can store a "use password method X" number along with the account. UPDATE - The problem here is that the hashing method might be cemented into place in the viewers. Also should work out what the restrictions on passwords are, and display them at password create / change time. Though things like password length limit is viewer dependent. |
|
|
I may have already taken care of this sort of attack, but double check it anyway - cookie security |
|
|
WebAuthn is probably a good idea for 2FA and 3FA. https://arstechnica.com/information-technology/2019/12/idevices-finally-get-key-based-protection-against-account-takeovers/ Also - https://www.theregister.co.uk/2020/02/04/security_key_google_opensk/ for DIY. |
|
|
Does it support physical security keys? |
|
|
Yes, it's the new open standard for physical security keys and biometrics. So finger prints, face scans, Yubikeys and such. Apple was dragging their heels supporting it, now they do, so now all the big players support it, which is what the linked article is about. 3FA is three factors, the traditional "something you know, something you have, something you are", password, key, fingerprints respectively. 2FA is any two of those. |
|
|
The basic account creation, and admin approval stuff is done. Enough to let people create accounts. That's the very important show stopper bit, so I'll decrease the priority of this task now. |
|
|
https://www.theregister.com/2020/04/30/email_http_leakage/ Yet another privacy issue I'll have to keep an eye on for later. |
|
|
https://arstechnica.com/information-technology/2020/07/apple-has-finally-embraced-key-based-2fa-so-should-you/ Includes some more general info. |
|
|
For the validation link, they should have to log in before they can use it. Helps avoid problems with email address typos that end up going to someone else, since someone else wont know the password. |
|
|
CRLF injection attacks is something I don't recall guarding against. Wikipedia OWASP |
|
|
"But it doesn't protect against injecting HTML. If the web application takes a field in the database and renders it on a page as HTML instead of text, you have an opportunity to get the page to run your own Javascript in what is known as an XSS attack. This is typically combined with spear phishing an administrator so you can exfiltrate their credentials when they load the page." Double check I'm doing something about this. |
|
|
Send moar emailz! Send one to admins when new member validates, or at least those that opt in. Send one to new member when they are approved, with instructions on what to do next. |
|
|
https://fidoalliance.org/UX-guidelines/ More passwordless stuffs. |
