I get that if you want to use an external login page for your hotspot, you can simply create a form with hidden fields on the mikrotik, and set those to send info to your external page.
This is outlined here: http://wiki.mikrotik.com/wiki/HotSpot_e ... login_page
Perhaps my question is also answered on the same page, but I'm not able to wrap my head around it - once a user is redirect to the external page and logs in, how exactly does that external page tell the mikrotik that the user has logged in, and that they are now allowed to use the internet for X amount of time? How does it communicate back to the mikrotik?

Anyone know how this happens?

With this form tag and the input fields contained between the tags.

<form method="post" action="http://<DNS name of Hotspot>/login" target="_self">

You specify a DNS name of the hotspot along with a local IP address that can be reached by the local user. When they click on the submit button it will post to that DNS name which resolves to a local address.

Interesting...

I'll be taking a closer look into this.
Thanks for pointing me in the right direction.

According to this:

http://wiki.mikrotik.com/wiki/Manual:Cu ... ng_Hotspot

the form that gets sent from the external page to the mikrotik looks something like this:

There's a fundamental issue that I see however:

My external login page keeps usernames and passwords in a MySQL database. The passwords are stored as salted hashes, and not in cleartext. After creating a user on the external page, there is no way for my external web server to know what the user's password actually is - that's by design. This means I am not able to use PAP, or CHAP to send the user's password to MikroTik, as I don't know what it is. Is it possible for my web server to just tell the mikrotik to login a particular user without checking the password, since:

1. Communication between the web server (external login page) and the mikrotik will be secure (HTTPS)
2. The mikrotik can trust the external web server is who it says it is for the same reason - HTTPS
3. If the user already logged into the external login page, then he is authenticated. No need to authenticate them again.

Edit:

Perhaps what I need is to have a RADIUS server with the same usernames as my external login page, and the same hashed passwords - maybe they can even use the same database table.
When my external page redirects to /login on the mikrotik, it will use PAP to send the hashed version of the password to the mikrotik.
At that point, the mikrotik will ask the RADIUS server if the password is right, and the RADIUS server will compare the 2 hashed strings, rather than the actual password, and allow access for the current user.

I think I just realized my problem: what I made was a login page that talks to a MySQL database, where it stores its usernames and passwords.

The idea of an external login page however is that the user enters his username and password into that page, and the page sends that info directly to the mikrotik device. The mikrotik will check either its internal database of users, or the RADIUS server it is configured with to see if the username/password is correct.

That sound about right?

You are correct. The idea is that the user must log into the network and accept a ToS to get online. The router takes in the information posted by the user and checks to see if that combination is correct and will get the attributes for that specific username/password either from the profile or from a Radius server, or both.

By using an external login page you are able to use a full featured web server instead of needing to rely on the limited built in one. This would for example allow you to use a templating system to change the look and feel of all login pages at once instead of needing to upload new html files to each router.

How would one transmit and store passwords securely with this setup?
Does this make sense?

1. Use HTTPS on MikroTik
2. Use HTTPS on External Login Page
3. When someone creates a user, hash their password and store it in the RADIUS MySQL table as a hashed value
4. When user tries to login on external page, immediately hash the password and send it to MikroTik.
5. The MikroTik will compare the hash the external page gives it against the one the RADIUS server has recorded, without actually knowing it's a hash - it will think that's the actual password string

That way, you only need to store hashes in RADIUS' MySQL database, and not actual user passwords.

Encrypting/hashing the passwords are kind of tricky, this wiki post talks about them.

http://wiki.mikrotik.com/wiki/Manual:Ho ... entication

You can use HTTP CHAP for doing the login, but then the session isn't encrypted, but there is a hash done on the password. But it does require JavaScript on the client side of things, so may not be the best choice. Also you would need to figure out what is sent and use the correct procedure on the RADIUS server to have it work.

HTTPS works, and you can probably do the CHAP thing again within the external page and figure out that mechanism if you wanted an extra layer of security about it (not a web developer so I wouldn't really be able to point you in the right direction for that). The problem with using HTTPS though is certificates. Yes you can get a valid cert and it work fine for the hotspot, the issue comes in when you need to redirect an end user to the login page. You can grab a HTTP request and push them to a HTTPS site, but you cannot transparently redirect HTTPS without a browser seeing it and throwing up a warning. All hotspot systems have that limitation though.

Mikrotik HTTP chap uses MD5 to hash passwords.
A relatively affordable setup of GPUs can generate 200 billion MD5 hashes per second:

https://gist.github.com/epixoip/a83d38f ... 804a270c40

On my external login page, I can use bcrypt, which is configurable in its slowness of computation, but an average hash can take about 0.1s to generate, which means several CPUs working together can generate at best 100 bcrypt hashes per second.

Is there some issue with the way I outline the steps? It seems that if they work, I'd be able to use any hashing algorithm I want, including bcrypt, as the RADIUS server would simply store the hashed version of the password as a string - as far as it would be concerned, the hash IS the password.

HTTPS would probably take some thought and testing to figure out - like you said, redirecting pages with HTTPS can be tricky. I have not gotten to that point yet.

Not a web dev or coder, but what your steps should in theory work. It's just a matter of development time and testing. Any hashing should probably be done client side, and as long as the client has the appropriate JavaScript, you should be able to hash it anyway that you desire. I believe that MikroTik just takes in whatever values are sent to it via the POST and then submits it to RADIUS. If you wanted to be more secure you could also use IPSec to encrypt the communication between the router and RADIUS.

The issue you will likely run into however are going to be the paranoid users that disable JavaScript and won't enable it. There won't be a way for them to generate a hashed password.

Client side hashing probably makes sense if you expect to have thousands, or millions of users so you don't need to waste your own processing power hashing passwords, but with as few users as I'm expecting, it probably doesn't matter too much if hashing is done on client or server. In fact, one advantage of doing it on the server is that clients don't need javascript enabled.

I'll give my idea a try - hopefully I can get it going. If not, I might have to resort to using HTTP CHAP, or think of something else.

Thanks for all the help.

The problem with server side hashing you may run into is preserving the information the MikroTik needs to sign in the appropriate user. If the server is doing the hashing, the client doesn't really know anything about it, and therefore the information will need to be submitted by the server on behalf of the client instead of the clients browser.

The MikroTik may not get all the information it needs to submit the credentials to RADIUS for the appropriate user, or it may just flat out refuse to acknowledge the POST.

When the user creates an account, they specify a password for that account.
At this stage, the password goes through the bcrypt hashing algorithm, which does a few things:

• It generates a unique salt
• It generates a hash of the salt + password
• It returns a single string, consisting of the salt, and the hash

This string gets saved to the RADIUS server as the user's password.
When the user tries to login, the external page will:

• Read the entire password string from the RADIUS database for the username specified
• Figure out the salt part of that string
• Use the password just supplied by the user, along with the salt to generate a hash
• Format a string to be sent to the mikrotik the same way the RADIUS server would have it - the salt and the hash
• Send that string to the mikrotik as the password

The mikrotik will ask the RADIUS server if the password supplied is accurate.
Either the hashes match, or they don't.
As far as the MikroTik and the RADIUS server is concerned, the string that bcrypt generates IS the password - they don't need to know about any hashing algorithms.
As far as the user is concerned, the password he supplies is the password - he doesn't need to know about what hashes are being used, or any other info apart from the username and password.
The external login page will do all the hashing and hard work, which for the most part isn't all that hard.

If the mikrotik is able to handle a POST request, why would it matter what it's coming from, as long as it's formatted properly?

Here's what I figured out, in case anyone else finds this useful:

In its most basic form, if you have an external page, you need 3 pages on the mikrotik:

rlogin.html:

Redirects to your login page when client tries to access any other page, and is not logged in.
Where EXTERNAL_LOGIN_PAGE_IP is the IP address or domain name of your external login page.
The <style> element is optional. Here's its only purpose is to have the same colored background as my external page.

alogin.html

Required to login, and redirect user to the page they were trying to get to originally (before they were redirected to your external page).
Same thing here - <style> element is optional, and only used to have the same background as external page.

logout.html:

Used to log a user out. Redirects back to your external login page after user has been logged out.
Where EXTERNAL_LOGIN_PAGE_IP is the IP address or domain name of your external login page.
The <style> element is optional. Here's its only purpose is to have the same colored background as my external page.

External Page:

Now my external page has:

A logout button on a page the user sees when the are logged in
    Redirects to logout.html on the mikrotik (the page above), which logs the user out, and sends us back to the external login page
A login form
    User enters username and password, and that gets sent to the mikrotik (see below)
An account creation page
    In my case, when users get created, I make entries in my RADIUS server - I don't do anything with the mikrotik directly here

External Login Form: Where MIKROTIK_IP is the IP address of the mikrotik device.
Where EXTERNAL_LOGIN_PAGE_IP is the IP or hostname of the external login page.

This page will allow user to enter username and password, and send it to the mikrotik.
The mikrotik will either check its internal user/password database, or the RADIUS server you configured it with.
In my case, before I send the username and password to the mikrotik, I already know they are correct (my code is quite a bit more complicated then the one above).
If you are using the above code, you'll need a way to handle invalid username/password entries. You'd probably need another page like flogin.html on the mikrotik that will redirect back to a page on your external login page, and tell users the username/password was wrong.

You will probably need more content than that, but that's a good starting point.
To pass info from the Mikrotik back to the external page, use a form on the mikrotik with variables for values that the mikrotik will fill in.

I need help kindly on how to load an eternal authentication on my microtic to have no login credentials needed but will prompt a billing system and after successful payment it will login user for the period paid for. Someone assist me with any help on how to do \this. I am good at phpand i have made a php file to do the billing but i need help on how to integrate on my microtik login to load this from my domain and login user without login prompt.