Can't change username on ROS 6.43

nicolasemmanuelc · Wed Sep 12, 2018 1:41 pm

Hello, recently I upgrade my RBSXT5HacD to the lastest version available (6.43 stable) and after it reboot I login and try to change default username (admin) and I can not do that in winbox because the textbox are disabled, then I try throug CLI and get this massage

[admin@MikroTik] /user> set admin name=comunicaciones
failure: user name can't be changed

What I'm doing wrong? What change about "user" section I'm missing on this release?
Thanks! Have a good day!

Wed Sep 12, 2018 2:21 pm

Make a new user, then re-login. There are big security changes in last versions, rename is no longer possible.

nicolasemmanuelc · Wed Sep 12, 2018 2:26 pm

Thanks Normis! I will do that!

AlainCasault · Wed Sep 19, 2018 8:00 pm

Make a new user, then re-login. There are big security changes in last versions, rename is no longer possible.

Hello Normis,

Can you explain what this change addresses, what security recommendation is met.

I'm not a security expert, so I don't get it. "Create/Delete" ends up with the same result as "Rename".

Best regards,

whatever · Thu Sep 20, 2018 12:17 pm

The only technical reason I can think of is, that the username is now part of the salt for the new password hashes. Otherwise it might just be a case of "not yet implemented".

man · Thu Oct 11, 2018 5:25 pm

Also a bit strange for me.
So in order to secure an access to the admin panel we may only change the password?
Am i wrong thinking that changing of user name and password is much stronger protection then just a password?

fragtion · Thu Oct 11, 2018 6:21 pm

Also a bit strange for me.
So in order to secure an access to the admin panel we may only change the password?
Am i wrong thinking that changing of user name and password is much stronger protection then just a password?

I think it's safe to assume that changing the admin password to something "uncrackable" like a 20-character long string with special characters, and then creating a new admin user with your desired password, will achieve the same effective level of security as changing the admin username to your desired new username and then setting that to your desired password. I mean there's not a remote chance in hell that anyone is going to crack a 20-character long password string with special characters via brute force over telnet/ssh - they can forget it. So yeah, technically changing the username IS "theoretically" stronger, but in a case like this that advantage is almost totally negligible/non-existent.

Sob · Thu Oct 11, 2018 6:52 pm

@man: You can always create completely new user and disable/delete original "admin".

AlainCasault · Thu Oct 11, 2018 9:49 pm

@man: You can always create completely new user and disable/delete original "admin".

+1

I agree. Deleting "admin", even if it has a pwd from hell is that much more secure.

Sent from Tapatalk

man · Fri Oct 12, 2018 12:47 pm

Thanks guys!
I want to create a HotSpot and need to be sure that system will be "Hacker resistant" ( sure i know that if some one really want to hack a system it will be done...)
I have already blocked all pings from Hotspot network at firewall filter and so on ...

AlainCasault · Fri Oct 12, 2018 3:21 pm

Thanks guys!
I want to create a HotSpot and need to be sure that system will be "Hacker resistant" ( sure i know that if some one really want to hack a system it will be done...)
I have already blocked all pings from Hotspot network at firewall filter and so on ...

I like your choice of word, "resistant". You look like someone who understands that nothing is ever "proof".

Cheers,

Sent from Tapatalk

macsrwe · Thu Feb 14, 2019 8:12 am

@man: You can always create completely new user and disable/delete original "admin".
+1

I agree. Deleting "admin", even if it has a pwd from hell is that much more secure.

And for those of us who have already been doing that for years with an initialization script, MikroTik has just made that even more difficult.

vecernik87 · Thu Feb 14, 2019 8:29 am

And for those of us who have already been doing that for years with an initialization script, MikroTik has just made that even more difficult.

Not really. I implemented my init script this way before it was enforced:

/user group
set full name=full policy=local,telnet,ssh,ftp,reboot,read,write,policy,test,winbox,password,web,sniff,sensitive,api,romon,dude,tikapp skin=default

/user
:do {
add address="" disabled=no group=full name=myadmin
} on-error={};
set	myadmin address="" disabled=no group=full password=NobodyWillGuessThis
remove [find (name="myadmin" = false)]

it does not depend on what user(s) exist. It just make sure that "full" group is really full, create new "full" user and delete every single user except this one. I would say pretty failproof...

anav · Thu Feb 14, 2019 6:31 pm

vecernik87 BURNS macsrwe!!

But how can you get mad a a playful colourful pony!

macsrwe · Thu Feb 14, 2019 6:47 pm

set full name=full policy=local,telnet,ssh,ftp,reboot,read,write,policy,test,winbox,password,web,sniff,sensitive,api,romon,dude,tikapp skin=default

it does not depend on what user(s) exist. It just make sure that "full" group is really full, create new "full" user and delete every single user except this one. I would say pretty failproof...

Which means you have to be careful to chase every new permission that MikroTik adds to the system. As I said, more work.

Looks like I was wrong to assume that RouterOS would not let a script delete the user under which it itself is still running. Perhaps some day they'll "fix" that too, and then this will all break again.

vecernik87 · Fri Feb 15, 2019 2:29 am

@anav: this pony can kick really hard

@mascrwe: good point! thank you. I actually haven't think this way and it might bite me in the ass later. fixed:

/user group add name=temppolicy   
:local defpolicy [:tostr [/user group get temppolicy value-name=policy]]
:local fullpolicy
:for i from=0 to=([:len $defpolicy] - 1) do={ 
  :local char [:pick $defpolicy $i]
  :if ($char = "!") do={:set char ""}
  :if ($char = ";") do={:set char ","}
  :set fullpolicy ($fullpolicy . $char)
}
/user group remove temppolicy   
/user group set full policy=$fullpolicy

audiomation · Tue Feb 19, 2019 4:06 am

@vecernik87 - this is brilliant. Thanks so much for posting.

However, I was going nuts because your script looked fine, but always failed with a syntax error at column 8 on the :set fullpolicy command in the loop. Couldn't figure out why it wasn't working for me.

Figured out that, for whatever reason, on RouterOS 6.43.7 on an RB4011, it will fail that way if run in verbose mode. If I don't run in verbose mode it works fine.

If anyone has an explanation that would be great. I've seen weird things happen in verbose mode that didn't happen when not in verbose mode before, but I'd forgotten about that until tonight.

macsrwe · Tue Feb 19, 2019 4:19 am

Figured out that, for whatever reason, on RouterOS 6.43.7 on an RB4011, it will fail that way if run in verbose mode. If I don't run in verbose mode it works fine.
If anyone has an explanation that would be great. I've seen weird things happen in verbose mode that didn't happen when not in verbose mode before, but I'd forgotten about that until tonight.

Any time you use :local outside a set of curly brackets, the results will be indeterminate depending on under what environment you execute the script.

vecernik87 · Tue Feb 19, 2019 5:57 am

@macsrwe: gosh! I didnt know

i wrongly assumed that any inner instance of curly brackets will inherit all variables from outside.
Thanks for pointing that out. I didn't really want to use "global" variable to avoid messing with rest of system, but I guess there is not much choice, is there?

macsrwe · Tue Feb 19, 2019 7:52 am

I think maybe I didn't state this entirely clearly.

If you have a :local in a script outside ALL curly brackets, its behavior is nondeterministic. For deterministic behavior, put one set of curly brackets around the entire text of the script. And yes, once you have a nicely deterministic variable, it is inherited properly inside all inner curly brackets.

vecernik87 · Thu Feb 21, 2019 12:15 pm

I think maybe I didn't state this entirely clearly.

Ohh! now it makes way more sense!

thanks heaps for this clarification! you really deserve cookies (or internetz or kudos or whatever currency you like)!

audiomation · Fri Mar 08, 2019 7:44 pm

Both vecernik87 and macsrwe deserves kudos, cookies, beers, whatever. This is an amazing community. Thanks for the help.

Can't change username on ROS 6.43 [SOLVED]

Can't change username on ROS 6.43

Re: Can't change username on ROS 6.43 [SOLVED]

Re: Can't change username on ROS 6.43

Re: Can't change username on ROS 6.43

Re: Can't change username on ROS 6.43

Re: Can't change username on ROS 6.43

Re: Can't change username on ROS 6.43

Re: Can't change username on ROS 6.43

Re: Can't change username on ROS 6.43

Re: Can't change username on ROS 6.43

Re: Can't change username on ROS 6.43

Re: Can't change username on ROS 6.43

Re: Can't change username on ROS 6.43

Re: Can't change username on ROS 6.43

Re: Can't change username on ROS 6.43

Re: Can't change username on ROS 6.43

Re: Can't change username on ROS 6.43

Re: Can't change username on ROS 6.43

Re: Can't change username on ROS 6.43

Re: Can't change username on ROS 6.43

Re: Can't change username on ROS 6.43

Re: Can't change username on ROS 6.43

Who is online