As I can see in 6.43rc changelog, there'll be very strange (ok, unexpected) news:

!) api - changed authentication process (https://wiki.mikrotik.com/wiki/Manual:API#Initial_login);

In fact, the login process should send login data differently:

Pre-6.43 login looks like this:
6.43+ process should be like this:
Dispute the general idea if the change is necessary at all, I expect all old API libraries (see https://wiki.mikrotik.com/wiki/Manual:API#API_examples) become obsolete, isn't it?

So my question is, will there be a way to keep login process as it was before? And, will there be any recommended changes to API libs to reflect these two different way of login and how API lib can tell the difference to choose right way while login?

We've just tested the API with a PHP API class and we're still able to communicate and operate on the Mikrotik with v6.43. No changes were required thankfully.

We've just tested the API with a PHP API class and we're still able to communicate and operate on the Mikrotik with v6.43. No changes were required thankfully.

Great news! Hold my RBs upgrade due to automation setup via such 'old' lib, now will test!

Watch out for the Winbox lockout - people are reporting login issues after the upgrade at viewtopic.php?f=21&t=138995

This does not apparently seem to be a forced change on how the login process works with the API. We have upgraded an in house device to 6.43.4 so that we could begin testing as we use the API service for a lot of in house functionality. If we still send the /login on its own we are receiving the =ret=... response and it still appears to work just fine. In fact none of our code was changed and we login without issue.

Is this supposed to be the case? Is this method planned to be eliminated in the near future?

Thanks!

Is there a fix out for this for PERL? Just upgraded a few devices from 6.44.x to 6.45.1 and now the API fails to log in. I have been using the CPAN installable which says it is version 1.0.5 and is up to date.

I had forgotten about the change last year to the API login process, but it now appears to be forced to the new method for 6.45 and forward. Is there any patch I can install to 1.0.5 to get this fixed? Maintaining 300+ Mikrotiks from a database and having a broken API slows me down.

Of course I can fix it myself if someone can explain what the change actually is. The manual says to now send =PASSWORD= on the first call, then send the user/password in plain text in the first command. Do I just send it =NAME=admin=PASSWORD=[password]???

Well that was easy...figured it out and patched my installed copy of the API code. I'll see if I can get this pushed as a change to the CPAN 1.0.5 version. Won't be today though, I've got testing to do on 6.45.1.

For those of you in the US, have a great holiday!

Code below. Added six lines, wrapping the old login code inside an if for failure of the new method: Indentation is what makes it look like a huge change.

root@blinkBSD:/usr/local/lib/perl5/site_perl/MikroTik # diff API.pm API_1.0.5.pm
151a152
>
153,154d153
< push( @command, '=name=' . $self->get_username() );
< push( @command, '=password=' . $self->get_password() );
155a155,167
> if ( $retval > 1 ) {
> die 'error during establishing login: ' . $results[0]{'message'};
> }
> my $challenge = pack("H*",$results[0]{'ret'});
> my $md5 = Digest::MD5->new();
> $md5->add( chr(0) );
> $md5->add( $self->get_password() );
> $md5->add( $challenge );
>
> @command = ('/login');
> push( @command, '=name=' . $self->get_username() );
> push( @command, '=response=00' . $md5->hexdigest() );
> ( $retval, @results ) = $self->talk( \@command );
158,176c170
< @command = ('/login');
< ( $retval, @results ) = $self->talk( \@command );
< if ( $retval > 1 ) {
< die 'error during establishing login: ' . $results[0]{'message'};
< }
< my $challenge = pack("H*",$results[0]{'ret'});
< my $md5 = Digest::MD5->new();
< $md5->add( chr(0) );
< $md5->add( $self->get_password() );
< $md5->add( $challenge );
<
< @command = ('/login');
< push( @command, '=name=' . $self->get_username() );
< push( @command, '=response=00' . $md5->hexdigest() );
< ( $retval, @results ) = $self->talk( \@command );
< die 'disconnected while logging in' if !defined $retval;
< if ( $retval > 1 ) {
< die $results[0]{'message'};
< }
---
> die $results[0]{'message'};
179c173
< print 'Logged in to '. $self->get_host() .' as '. $self->get_username() ."\n";
---
> print 'Logged in to '. $self->get_host() .' as '. $self->get_username() ."\n";
root@blinkBSD:/usr/local/lib/perl5/site_perl/MikroTik #

This change can't be serious? Instead of challenge/response authentication the username and password are now sent in clear text?

"Progress"

Mikrotik, are there any explanations?
"Instead of challenge/response authentication the username and password are now sent in clear text?"

Where traffic can be easily sniffed by 3rd parties you should establish secure connection anyway.

Is there a fix out for this for PERL? Just upgraded a few devices from 6.44.x to 6.45.1 and now the API fails to log in. I have been using the CPAN installable which says it is version 1.0.5 and is up to date.

Sorry, I missed the fact that the old method has been removed with 6.45.
The changes (previously only on GitHub) are now also available with CPAN: https://metacpan.org/pod/MikroTik::API (v1.1.0). It precedencs new method and falls back to the old one.
Please test it carefully before production use, there were many PullRequests included in this release. Also some changed error handling (not dying so fast but use of errorcodes).

Also not very happy with plaintext auth method introduced with 6.43 (why???). So I postponed the release quite long.

"Where traffic can be easily sniffed by 3rd parties you should establish secure connection anyway."

Ok, now on not secured connection we have to pass password as open plain text, which is unsecured even more .
Are there any advantages of post-6.43 login method?

So to say, enable access from only trusted net is still best approach.

API is yet better thing in compare to ssh, but from insecure nets ssh can be used. Harder to integrate to scripts, yes.

At client side one call less is necessary to login. The only (extremely unimportant) thing I can say. I love MT products but the release policy is quite silly. There is also no explanation for those decisions like "killing MD5 saves xx% resources on the router" or something like that. Consequence is that most people will use ssl and set ssl_verify to none and think they are safe.
An absolutely unnecessary change in my opinion.

Hey, this way we will one day say "please add let's encrypt support" :)

The sad side many routers are far from the internet access themselfs anyway.

Silly policy, indeed. No sign it will be better one day.

The reason is new password storage. To keep md5 we would need to store password in plain text on the router, which is not what we want.
Do you use tenet over unsecure networks? I think not, most likely you will chose ssh instead. With api is the same, consider unsecure api as telnet, and api over ssl as ssh.

I am affected by this change too, it seems (using the PHP API from the link here: https://wiki.mikrotik.com/wiki/API_PHP_package). Authentication fails (I get login incorrect since moving from 6.43 to 6.45 (current LT).

[quote=leobg post_id=776655 time=1582573440 user_id=49361]
I am affected by this change too, it seems (using the PHP API from the link here: https://wiki.mikrotik.com/wiki/API_PHP_package). Authentication fails (I get login incorrect since moving from 6.43 to 6.45 (current LT).
[/quote]

Quite a problem MT has no official PHP (and other scripting languages as well) packages/libs that's stay current as API change. Yes it involves a lot to maintain that, but people keep rely on API, while libs become outdated if not supported.

Good luck to you! What I was able to find is https://github.com/EvilFreelancer/routeros-api-php this lib, it says "You can use this library with pre-6.43 and post-6.43 versions of RouterOS firmware, it will be detected automatically on connection stage."