Long time Mikrotik and RouterOS user and got my first POE switch yesterday. Cannot describe my surprise and disappointment when setting up a new password in SWOS v2.16. Can't change admin username to something else (normal practice), but more importantly: a 19 character password is too long!!! I've come to expect better than this from Mikrotik. I appreciate it's a switch and not a router but that's no reason for poor architecture and design practices.

What device are you referring to ?

Not being able to change user is a SWOS thing. Encountered that little problem as well on CSS610.
Also a reason why I keep several CRS326 switches on ROS, not SWOS.
(That and the MUCH more granular way of configuring that box using ROS)

Length of passwd is new to me (my CSS610 has a 16 character passwd).

Best to address your problem to support, they can provide you more info.

I don't think that a 18 characters long password can be that much insecure, generally speaking, or if you believe that your hypothetical attackers are capable of breaking that, you probably have much more serious things to worry about.

After all NIST minimum recommendation is 8 chars for user chosen secrets:
https://nvlpubs.nist.gov/nistpubs/Speci ... 00-63b.pdf
while longer passwords may be safer, it is not like past 12 or 16 you get in practice any particular advantage, as a matter of fact login attempt rate limiting is much more effective that lengthening the password, that anyway is only useful against brute-force attacks.

I don't think that a 18 characters long password can be that much insecure

I believe you're missing @mwiesenhaan's point. A length limit implies that they're storing the password in plaintext, thus that it can be retrieved and reused as-is.

If they were salting and hashing the password as has been standard practice since the 1980s, you could feed it a Tolstoy novel and it would still hash down to the same length. There will be practical limits involved — network receive buffers if nothing else — but that should be up in the kilobytes range, effectively infinite for the purposes of password inputs.

(Yes, 1980s. There is a classic 1978 paper on the design of the UNIX V7 password scheme here, which is more secure than is implied by the length limit on the password in SwOS. That ancient DES-based key stretching algorithm in Unix isn't precisely "hashing," but it's in the right vein. Note the authors of the paper: Ken Thompson, co-creator of UNIX, and Robert Morris, father of the infamous author of the Morris Worm.)

There are too many institutions with password limits. The worst are those which do not advise their limit but silently discard any text beyond it.

I don't think that a 18 characters long password can be that much insecure

I believe you're missing @mwiesenhaan's point. A length limit implies that they're storing the password in plaintext, thus that it can be retrieved and reused as-is.

Not necessarily.
There might be a (unneeded) length check upfront before feeding it to the hash function.

A sensible limit of that type will be based on a buffer size, as I indicated. 256 bytes is sensible. 1k is sensible. 64k is sensible. 18 smacks of a fixed-length plaintext field in a C structure stored as-is in the flash RAM; there are no common 144-bit hash functions.

What they ought to use that space for is 2 bytes of salt and a 128-bit hash output.

A sensible limit of that type will be based on a buffer size, as I indicated. 256 bytes is sensible. 1k is sensible. 64k is sensible. 18 smacks of a fixed-length plaintext field in a C structure stored as-is in the flash RAM; there are no common 144-bit hash functions.

Keep in mind that we're talking about SwOS which is limited by capabilities of switch chip (on devices which don't support running ROS). So any buffers exceeding MTU (minus some application overhead) might not be sensible as the SwOS-side software might not be able to "de-fragment" buffers received ... remember that SwOS lacks full-featured IP stack as well (it doesn't support routes, it doesn't support "native" software update checks, etc.). SwOS also lacks support for https, which IMO is much bigger problem than password length limitation.

I don't have an immediate concern about a breach on my switch (CRS328-24P-4S+RM), it's more that I would classify this as poor software engineering practices. Based on ROS, my experience (and expectations) are a lot higher than this. And it's not something that couldn't be fixed in a sprint or 2.

BTW the link to the NIST document recommending 8 character passwords, that recommendation is from 2017. I find it hard to belief that anybody would consider that secure today. And if you're very confident on the security of a 8 character password, please share your 8-character secured bitcoin wallet with me (no harm intended)

Please stop using passwords use ssh keys instead.

When your router supports it (and the CRS328-24P-4S+RM does), install RouterOS instead of SwOS.
SwOS is just a toy, for those that have very limited requirements (and switches with tiny capabilities).

BTW the link to the NIST document recommending 8 character passwords, that recommendation is from 2017. I find it hard to belief that anybody would consider that secure today.

It depends on what type of rate-limiting is in place in front of it.

That's why I bothered to set up fail2ban in front of RouterOS here. With that in place, 8 characters is plenty.

Not that my remote-login passwords are that short.

Please stop using passwords use ssh keys instead.

The thread is about SwOS, which doesn't support SSH.

Please stop using passwords use ssh keys instead.

The thread is about SwOS, which doesn't support SSH.

Thanks @tangent i didn't know that, Mikrotik should implement that, add it to the christmas wish list .

Use proper VPN to get into your network, then use plain text passwords as much as you want.

BTW the link to the NIST document recommending 8 character passwords, that recommendation is from 2017. I find it hard to belief that anybody would consider that secure today. And if you're very confident on the security of a 8 character password, please share your 8-character secured bitcoin wallet with me (no harm intended)

Yep, but we don't have a limit at 9 characters, we have it at 19, i.e. NIST says no less than 8, SWOS says no more than 18 (and the document has been revised in 2020 without editing that part).

And it is not something you can - I believe - bruteforce offline.
If you have set some sensible rules to prevent access to the login page of the router from outside LAN and - possibly - even from any IP address on the LAN but a single one, it would be difficult to even attempt accessing the login page.
But, when you have access, there is also an implied rate-limiting, when brute-forcing (say) a .rar archive password specialized hardware (GPU's) is often used to increment the possible attempts from thousands passwords per second to tens or maybe hundreds thousand password per second.

I wonder how many password per second you can "feed" the login page of a Mikrotik before it errors out, possibly a few tens?

Now, if tangent is right and the password is stored in plain text (which I doubt), still you have to either use the login page with its limits or dump the device memory, this latter implies both physical access and taking the device out of the network.
A clever attacker could replace the Mikrotik device with an identical one with an identical (or similar enough) configuration in a few seconds/minutes, of course, the short downtime would probably be attributed to a glitch of the matrix.
The "fake" machine should however behave exactly like the old one did.
To do this this hypothetical hacker would need to observe your network behaviour and rebuild a "good enough" configuration from the way the device behaves, but as soon as something won't work on the "fake" machine the network admin will attempt to access the device and find out that the "old" password doesn't work anymore and suspect something or however fix the configuration and make a new password.

The processor in the switch chips on SwOS-only devices is very limited so it is highly unlikely that any encryption can be added. From the Marvell datasheet Target Applications section "Smart and Lightly Managed switches: Integrated microprocessor enables lightly managed switches with the addition of an external EEPROM"

The password will likely be stored in a fixed location of the EEPROM, and certainly is transmitted and saved in hex-encoded plaintext when you backup the configuration - open the .swb file in a text editor and you will find an .pwd.b:{B:'xxxxxxxxxxxxxxxx'} entry.

The processor in the switch chips on SwOS-only devices is very limited

Yes, but his (TS's) switch is not SwOS-only. He says he is a long time RouterOS user.
He can just install RouterOS on his switch and have the familiar interface, password capabilities, SSH/https access etc he knows from RouterOS.
So why complain about SwOS? I don't complain about computers coming with Windows, I just install Linux.

Not only does the same hardware run high-security crypto algorithms just fine (VPN, SSH, HTTPS…) the web login use case is on the order of one per hour. As long as the salt+hash computation completes in ~1 second, it’s fast enough.

Yes, but SwOS-only switches like the CSS610 come with only 64KB of storage!
That is way too small to install a complete operating system with all kinds of functionality.
So SwOS was developed with only a simple WEB interface to manage setup of the switch chip.
That is OK, but of course it will be limited. On a switch with 16MB of storage you can install RouterOS and have full functionality.
(even 16MB is not much, but MikroTik still manages to put full RouterOS in it... sometimes it overflows but after complaints they manage to shrink it again so that it fits)

Yes, but SwOS-only switches like the CSS610 come with only 64KB of storage!

That one uses SWOS Lite.
That's again another version...