Hi @<1687643893996195840:profile|RoundCat60>

anyone with access to the server

Is that a thing? If you have access to the server Not sure how "protected" you are even if using a key ring...
(unfortunately I do not think we support anything else, but what did you have in mind?

Some ideas, not all directly related to this:

• Passwords should be encrypted before being stored
• A mechanism on the server application to add/remove users, avoiding having to SSH on to the server would be nice
• Some level of permissions in the application would be nice - Admin/Owner/Viewer restrictions which would dictate would users can do and give finer control

Hi @<1687643893996195840:profile|RoundCat60> ,

Passwords should be encrypted before being stored

That's definitely an option (we had the same idea), however it would mean a more complex configuration procedure and might male it hard for less-savvy people to setup the server. Considering the fact that anyone with access to the server can basically access all data anyway, as @<1523701205467926528:profile|AgitatedDove14> said, having the passwords for the account encrypted won't make or break you protection 🙂 .
BTW - if you're using AWS EC2, you can easily use the AWS Secrets Manager to store this information.

Thanks. Where is the configuration stored on the server? Currently we have deployed an EC2 instance using the marketplace AMI - if this demo is successful we would be looking at splitting the environment into the different AWS services - logging to S3, use of secrets manager, elasticsearch, redis, mongoDB etc

I've looked through the documentation, but didn't initially spot anything that would help with doing this (granted I may have overlooked something)

The configuration can be provided using a configuration file (like apiserver.conf or services.conf ), or provided to the server as an environment variable (every configuration setting can be set using an environment variable in the form TRAINS__<path__to__configuration__setting>=<configuration value, base type of HOCON configuration format> )

For example TRAINS__APISERVER__AUTH__FIXED_USERS={"enabled": true, "users": [{"username": "foo", "name": "Foo", "password": "bar"}]}

I’m interested to understand how we can use secrets manager for password storage. Do you have any documentation on this?

Hi @<1687653458951278592:profile|StrangeStork48> , the easiest way is to read Amazon's AWS docs regarding the Secrets Manager. Once you manage to use that, you can simply "inject" any values you require into config files or environment variables.

Ah ok, so you don’t support secrets manager per se, you’re suggesting we build our own auth system using it?

this would not solve the issue of server admins knowing everybody’s passwords would it?

That's right 🙂

This seems to me quite a fundamental security issue. Do you have a roadmap which includes resolving things like this?

Hi @<1687653458951278592:profile|StrangeStork48>

secrets manager per se,

Quick question, are you running the trains-server over http or https ?

Do you have a roadmap which includes resolving things like this

Security SSO etc. is usually out of scope for the open-source platform as it really makes the entire thing a lot harder to install and manage. That said I know that on the Enterprise solution they do have SSO and LDAP support and probably way more security features. I hope it helps 🙂

Quick question, are you running the trains-server over http or https ?

We’d be using https in production

We’d be using https in production

Nice 🙂
@<1687653458951278592:profile|StrangeStork48> , I was reading this thread trying to understand what exactly is the security concern/fear here, and I'm not sure I fully understand. Any chance you can elaborate ?

The concern is that user’s passwords are stored in plain text.

Assuming it was hashed, the seed would be stored on the same server, so knowing both would allow me the same access, no?

If you can reverse the hash you’re doing it wrong. A hashed password should be of no use to anyone, that’s the whole point. The application should only ever compare the hashed values of a password. This is basic application security.

Hi @<1687653458951278592:profile|StrangeStork48>

• Agreed,
• Notice this user/pass is only used for the initial authentication, after that all authentication is done via a signed JWT tokenHow about a GitHub issue with the feature request, if there is enough interest (or someone jumps in offering implementation) we can push it forward. What do you think?

Hi @<1687653458951278592:profile|StrangeStork48>
I have good news, v1.0 is out with hashed passwords support.

• Set hashed passwords with  pass_hashed: true
• Generate passwords using  python3 -c 'import bcrypt,base64; print(base64.b64encode(bcrypt.hashpw("password".encode(), bcrypt.gensalt())))'  (obviously, replace "password" with the actual password). The resulting b64 string should be placed in the password field for each user.
  For example, assuming your password is "123456":
• bash:

> python3 -c 'import bcrypt,base64; print(base64.b64encode(bcrypt.hashpw("123456".encode(), bcrypt.gensalt())))'
b'JDJiJDEyJDk3OHBFcHFlNEsxTkFoZDlPcGZsbC5sU1pmM3huZ1RpeHc0ay5WUjlzTzN5WE1WRXJrUmhp'

• In  apiserver.conf  :

# A list of fixed users
fixed_users {
  enabled: true
  pass_hashed: true
  users: [
    {
      username: "john"
      password: "JDJiJDEyJDk3OHBFcHFlNEsxTkFoZDlPcGZsbC5sU1pmM3huZ1RpeHc0ay5WUjlzTzN5WE1WRXJrUmhp"
      name: "john doe"
    }
  ]
}

Great news! Thanks Martin.

FYI - this is also documented in None