SMS Authentication of Users in Omada Hotspot Portal Server
SMS Authentication of Users in Omada Hotspot Portal Server
We are trying to use to use SMS Portal authentication for our *now 59 AP EAP Wifi System in India. We are currently using a password based mechanism to authenticate users (which works just fine), but now are forced to move to SMS authentication for compliance with the country's regulatory norms for Public-Wifi.
Have a few questions:
(1) First (Blue Box), does TP-Link have a plan or method to support any non-Twilio Bulk SMS provider with the Omada Hotspot System ? Or it will be only Omada+ Twilio or 3rd Party Hotspot Application Server integrated with its own Bulk SMS provider service. ? Twilio Bulk SMS in India is an international SMS VAS service and from the plans put on their websitre look to be 12-24 times or more expensive than Local Bulk SMS providers in India.
(2) Second (Read box) mentions authentication timeout which I am able to set from 1 minute to almost 30 days. If I understand this *correctly, it means that once authneticated by portal (i.e. the OTP from received SMS is validated by Omada Hotspot App Server), the system will retain this authentication for configured timeout period (max. 30 days) and will not *present the Portal Page and challenge user for OTP authentication for the authentication period. Is my understanding correct ?
(3) Thirdly, Is their a way for system administrators to access the authentication record (log) and see that which Client (MAC-ID) was authenticated using what Mobile No. (that received SMS) and was assigned what IP and this happenned at what time. This N-tuple Information we heard is required to be archived and accessible by law-enforcement to track the perpetuator of any cyber crime using the Hotspot.
The country regulatory norm for Wifi and issues plaguing the ecosystem are summarized here:
https://factordaily.com/public-wifi-could-finally-be-coming-in-from-the-cold/
- Copy Link
- Subscribe
- Bookmark
- Report Inappropriate Content
@R1D2 :
I think 99% of the portal functionality is same between all countries and for the remaining fringe 1% requirement of divergence (such as this law enforcment support one), it may be a big economic waste to replicate and create something from scratch with the intention of addiing only 1% value. I just see a new use supplied portal integration opening a very big can of worms. Only software R&D forms would do that. I get however that why TpLink may not be interested to implement this, but if they could just give their customers outside Germany a way to implement this easily (configuration, country specific firmware feature, exposed API, etc), then maybe it will work for all parties.
From my point, In India also, and my residential their is no mandate for admins to snoop, but just be compliant with country's legal system. Admins do not have any trigger point to start any investigation/snoop (unless law enforcemet comes with a complaint) on any connection amongs thousands in a day. But what I am keen to see that the information system logs or maintains is useful for the law enforcement to identify the suspects or better the criminal. Right now everything is in bits and pieces, scattered, bloated, unfriendly to use which takes away from goal . Plus i see that 90% of relevant information and key technique rests to implement this well rests with the firewall rather tnan the Hotspot Application Server.
The "unknown" hostname business is more dangerous. their can be many unknowns. One more reason why any investigation of this sort should start from firewall, not Omada Hotspot App Server
R1D2 wrote
the problem I see with legal requirements in India or France is that they violate the laws in other countries. For example, if TP-Link would add personal information to Omada controller as per your request, the Omada Controller could not be used anymore in countries which have strong data protection laws such as Germany.
In Germany it's strictly forbidden to record any personal data such as the MAC address or IMEI number for an unspecified time if it is not used for billing purposes or to fulfill contracts. According to a ruling of the german highest court, MAC addresses are personal data. For technical reasons, a MAC address can be stored for a very short time only, e.g. for 7 days, to be able to mitigate against DDoS or other attacks. But after a week it must be (physically!) deleted.
What's more, ISPs are not deputies to law enforcement. In Germany, it is not even permitted to carry out investigative activities yourself, as this is a sovereign task that only the authorities are allowed to perform (violations are punishable by law, too).
Authorities in Germany can neither request to store records of login sessions on a public hotspot nor request them from the hotspot provider, only judges can order to store specific information about suspects in the future (but also not request any data from the past!).
The only solution I see to fulfill contradicting laws in different countries is to create an own hotspot portal (like our company did for Germany). The laws in different countries are just too specific to the country, which makes it extremly difficult to offer a turn-key solution for all.
APRC-P3-Tel, the name for an Android smartphone is the hostname Android sends to Omada controller as the WiFi hostname. Omada controller does just display what it gets from the client device (if it gets any name at all, otherwise it will show »Unknown« if the received WiFi hostname is empty).
- Copy Link
- Report Inappropriate Content
Thanks for your input, in general you may always run into issues with national law especially when it is about wifi hotspots. What I like about the Zyxel approach, it let you define which data to log on your syslogserver and which not. This allows you to decide which data is needed in your country by law to be handed over to the police. In this case it is the respnsibility of the Hotspot owner to make the right setup according to national law.
It is not about ourself doing some policing but to comply with the national hotspot rules. In France every public Hotspot owner is automatically an ISP and has to comply with the same rules as the big players. You also have to register with CNIL and apply the GRPD to the data you colletc etc. so yes in general in France it is a bit complicated to run your own hotspot thats why most hotels use a certified service provider or are using a product like the TP-Link solution and hope they will never get into trouble.
https://www.cnil.fr/fr/conservation-des-donnees-de-trafic-hot-spots-wi-fi-cybercafes-employeurs-quelles-obligations -> It is a summary from the regulation authority in French but GoogleTranslate might be your friend.
I really like the step Germany went by moving the responsability away from the hotspot provider, but I guess in most of the countries it is not the case. Please let me know if I am wrong.
Anyway, for sure you can ask every hotspot provider to put up a lot of developpement work and use pfsense or sophos captive portal and add loggings and sms voucher solutions etc. but for me the question is why does it always have to be that complicated? So having had a look at the current solutions that are more or less plug and play, the Zyxel UAG4100 is the only device that has it solved but the hardware is just so outdated. And even though it records the MAC-Adress it is still sold in Germany.
It would be just great to have a log setup where you can decide which guest data to be logged and send to a syslog server. You may put a warning that the settings might not comply with national law. Also TP-Link is not that small in France and they are offering to the customers the captive portal solution eventhough it does not comply with french law, putting many people using it in France at risk because they get the impression that it is a legit solution, so your argument for the german market where something is forbidden could be the same for the french one, if you understand what I mean.
Any way thanks for your input, and maybe TP-Link should add a warning to their product that the captive portal solution with sms validation does not comply with the french law. I just found the TP-Link solution by looking for sms-voucher hotspot and only found out by digging a bit deeper that it does not comply.
But who knows maybe france changes its law like germany and italy and makes it less problematic to run a hotspot.
Thanks
- Copy Link
- Report Inappropriate Content
APRC-P3-Tel wrote
I think 99% of the portal functionality is same between all countries and for the remaining fringe 1% requirement of divergence (such as this law enforcment support one), it may be a big economic waste to replicate and create something from scratch with the intention of addiing only 1% value. I just see a new use supplied portal integration opening a very big can of worms.
No, it's not only 1%, since laws change over time.
Don't get me wrong: I don't care whether Omada controller implements this or that method, since we use our own portal with Omada EAPs anyway. I just want to point out that a vendor can hardly fulfill all those different laws in effect world-wide. That's not possible and even much work for one country alone. Thus, we developed our own portal software back in 2006 and it's still in use today. It had to be changed many times since then (last change was just 2019 to comply with the EU data protection law, second last change was 2017 for the third amendment to the german telecommunication law, just to name a few).
Unfortunately, it's not that easy to use this own solution in other EU countries despite the claim that the EU is an union with almost identical laws (that's a nice fairy tale in fact).
And no, it does not open a big can of worms if your developers are professionals and you rule out Windows as a platform. What indeed brought our company such issues was the 1:1 port of Omada controller Windows version to Linux due to a buggy Java JRE8, but since Omada community version v2.6 the software was safe again and those modifications have been taken over in official Omada version since v3.0.2.
- Copy Link
- Report Inappropriate Content
Lens wrote
What I like about the Zyxel approach, it let you define which data to log on your syslogserver and which not.
This sounds like a good idea for the data to be recorded. But what if a judge orders you to inform the police immediately when a suspect with a MAC known to the police logs on? You would have to write a plug-in which scans MAC addresses and sends an email to the federal police.
This was the last order we (and every other hotspot provider) received from a judge when they searched for a guy who was blackmailing a corporation. Such extensions can only be developed when you know that authorities will demand this, but so far this was not demanded. These are functions of a Captive Portal that are not predictable.
In France every public Hotspot owner is automatically an ISP and has to comply with the same rules as the big players. You also have to register with CNIL and apply the GRPD to the data you colletc etc.
Yes, I know this. We once were thinking about offering hotspot services in France, too, but it's too complicated to fulfill the laws if you are not a native with experience in the law system and knowledge of the history of lawsuits regarding the subject.
I really like the step Germany went by moving the responsability away from the hotspot provider, but I guess in most of the countries it is not the case. Please let me know if I am wrong.
Unfortunately yes, you are wrong. The law-makers didn't move away the responsibility with the third amendment of the telco law. Yes, they said that they would move away the responsibility, but the said this twice before, too, and that's why recently a third amendment had been made. But what they did indeed was to strenghten the law: now even a lawyer can order a hotspot owner to block a website with copyrighted material somewhere on this planet on suspicion (fomerly a block order by a judge was needed and a suspicion wasn't sufficient for a judge to place such an order).
Now, how would you block a site in a Captive Portal? Not possible. You have to block it in the router's firewall or by poisioning the DNS server and forcing users to use only this DNS server. Next functionality you have to develop.
The only improvement of the third amendment of the telco law is the explicitly granted right for anyone to anonymously use telco facilities such as public WiFi hotspots and authorities can no longer demand to use an authentication scheme for logging into a public WiFi hotspot. Albeit this right on anonymity existed long before already, it wasn't always obeyed by local authorities, since the law didn't explicitly mention WiFi hotspots which didn't exist 70 years ago when the first version of the former telco law was written.
What's still in place are mechanisms to hold the hotspot owner accountable for copyright infringements of their guests using their hotspots. This is the responsibility they wanted to move away from hotspot owners, but as I wrote: in fact they did not. It was just the usual chatter of our politicians in order to win sympathy.
but for me the question is why does it always have to be that complicated?
I can't speak for France about your politicians, but in germany it's because detached people without slightest knowledge of IT make laws. :-)
That's why every governmental IT project in last 20 years ended in a fiasko, btw.
For example compare Internet-based home schooling in France with that in Germany. In France: it works since decades. You have developed this already long time before lockdown. In Germany it was discovered just now, but every teacher needs to improvise. Government was so far busy discussing gender themes and developing first unisex toilets or planning an airport capable of servicing an A380 which is already EOL now and still will be when the airport will become ready in 2030 or so (even no WiFi at this ariport!). No wonder that our Internet infrastructure is at the state of late 1990ies currently.
Back to the subject: A good idea would be to develop a common base for own Captive Portals which can be adapted to local laws.
Another idea would be to drive the incompetent people out of politics and law-making.
But who knows maybe france changes its law like germany and italy and makes it less problematic to run a hotspot.
I'm not sure whether this has been changed meanwhile, but when we studied the Italian laws to be obeyed when deploying a WiFi hotspot years ago, guests of a public hotspot needed to deposit a photocopy of their personal ID card and their exact usage times had to be recorded. So, a public hotspot system would have to provide a scanner, a printer and a time recorder if one demands a turn-key solution for Italy.
But the idea to provide optional logging facilities which can be selected is a good one, this could be implemented either by a common base for an external Captive Portal or by TP-Link.
- Copy Link
- Report Inappropriate Content
In France so far you just need to log the traffic (anti-terrorisme law). Means if they have some suspicion or a crime has been committed via your hotspot you just have to hand over the data which should give them a clue who could have done it. So mostly the combination of phone number an macadress would be what they are looking for in combination with time stamps and destination IP.
So up to now there is no law that can force a hotspot provider to block certain websites or Mac addresses in France.
For Italy they removed the ID obligation and made it far mor convenient for hotels and bars.
Anyway an optional logging from TP-Link would definitely help. What I find weird on the French website they advertise the captive portal for hotels etc. even though their system does not comply at the moment.
- Copy Link
- Report Inappropriate Content
Lens wrote
In France so far you just need to log the traffic (anti-terrorisme law). Means if they have some suspicion or a crime has been committed via your hotspot you just have to hand over the data which should give them a clue who could have done it. So mostly the combination of phone number an macadress would be what they are looking for in combination with time stamps and destination IP.
But you are aware that a Captive Portal based on redirection to a login page only for authentication won't log any traffic, even not source or destination IPs?
The traffic flow does not go through Omada Controller. Just the authenticaction is passed to the portal. Once authenticated, traffic flows through the router only. The Omada controller even don't notice the traffic, just byte counters in the EAPs are read.
What you would need in France is an interface on the router. ISPs have this information already, in Germany the authorities have a direct interface to the Internet exchange node DE-CIX. That's why we don't need – or more precisely are even forbidden – to record source and destination IPs.
Thanks for the clarification of requirements in Italy. Looks like they've come to their senses.
- Copy Link
- Report Inappropriate Content
- Copy Link
- Report Inappropriate Content
Deepbairwa wrote
Dear sir sms chargeble he kya
@Deepbairwa : Yes it is. $0.01 per SMS and 1$ per month fixed charges for line. Don't compare with Indian Country Bulk SMS packages as this is an international SMS. It works out very economical for us, is very reliable and stable and offers excellent management interface. Could not have asked for anything more.
- Copy Link
- Report Inappropriate Content
There are clearly two issues here as I see it.
The first seems to be some transparency and better understanding of the level of logging, and also, data retention within an individual collection of devices managed by the SDN controller. This is clearly very important as providers are required to maintain reasonable logging where they provide a public service like a hotspot. As has been stated, many countries even in EU are different (though we all (until Dec 31st, ha!) have to follow the same EU regulations.
Secondly is the greater requirement posed more by precedent and innuendo rather than law. This is the obligation to somehow control the websites to which users can reach. Additional to this is the onus of keeping track of all of these connections too. For this, my understanding is that the onus lies with the ISP who provides your connect 'to the internet'. Law enforcement would approach your ISP, first, to understand from which IP the connections came, and then contact the hotspot provider to match an IP to a MAC address and/or phone number.
Where portal owners need to keep track of connection data and/or block questionable sites this is a task which lies beyond any hopspot configuration, but which resides in the router and/or firewall design. For the most part, there remains more than adequate provision for this task within netflow or sflow recording. This can be able configured to retain JUST the data needed, and to keep it for as long as is needed. Again, here, platforms like Elasticsearch (ELK stack) are ideal.
Finally there is the perception that the only portal option is within the EAP/SDN software/hardware. In my home (homelab) network I use EAPs (with Omada SDN), a Dell Powerconnect switch and PFSense router/firewall. All three products here offer me portal options. If one size does not fit all, find another one which does.
- Copy Link
- Report Inappropriate Content
@Forrest: This is a 2 year old discussion thread. However their is a recent incident in my country which has slightly aggravated the situation wrt to choice of SMS provider. Indian Mobile Operators have have hiked tariffs for international SMS delivery, under which they are charging $0.03 USD (Rs 2.25 INR) to deliver SMS to Indian mobile network users. These types of hikes have taken place recently in last 2 years and going by the attitude of Indian mobile operators, this may further increase (in their defense they say that some countries charge $0.06 USD for international SMS and therefore the hiked rates are still way less than many other countries OR that the customers who these international SMS services can afford to pay increased tariffs.
The result is now Twilio's SMS service for Indian users is 50+ times more costly than local Bulk SMS providers. And we can expect another 50% jump in rates. Our volume of authentication SMS presently is not very high ($20-$30 per month or about 80-1000 SMS max per month for Twilio) and so it does not hurt much, but it is still an eyesore as 2 years back we used to incur a cost only $5 per month to operate our Wifi network with a 30 day validity of SMS authentication. This SMS volume is artificially depressed as we are using a 30 day authentication validity, when ideally we should use 1-2 hours. What hurts is that sometimes because of poor cellular coverage/capacity (that is why one switches to wifi network), sometimes SMS cannot be delivered reliably. We have seen that some wifi Users end up trying to get OTP SMS 5-10 times. before they actually get one or more SMS delivered and this just adds that user bootstrapping cost to our network to Rs. 15-30 which is very very unreasonable. In another setup with more rational SMS authentication validity periods and repeated footfalls, this could easily be hurting much ($100-$200 USD per month)
Maybe Tplink can reconsider the implementation
(1) You may ask Twilio to run SMS servers in india (local operations) and therefore rationalize the SMS tariff for Omada users
(2) You may open the SMS provider integration interface to support any 3rd party SMS provider, not just Twilio. Perhaps using RESTful integration, if this is feasible.
Twilio's services anyways are excellent and we are very happy with whatever we are getting, except that the SMS charges have started to become more noticeable and are only expected to move further northwards going by recent consolidation & cartelization in telecom sector of India.
forrest wrote
Here are the reply for your questions.
1. Does TP-Link have a plan or method to support any non-Twilio Bulk SMS provider with the Omada Hotspot System ?
==> For now, we have no plan to support other SMS provider other than Twilio.
2. I understand this *correctly, it means that once authneticated by portal (i.e. the OTP from received SMS is validated by Omada Hotspot App Server), the system will retain this authentication for configured timeout period (max. 30 days) and will not *present the Portal Page and challenge user for OTP authentication for the authentication period. Is my understanding correct ?
==> Yes, you are right.
3. Is their a way for system administrators to access the authentication record (log) and see that which Client (MAC-ID) was authenticated using what Mobile No. (that received SMS) and was assigned what IP and this happenned at what time?
==> Now we have added log about the authentication. You can see the anthentication from the log.
- Copy Link
- Report Inappropriate Content
Information
Helpful: 0
Views: 7257
Replies: 20
Voters 0
No one has voted for it yet.