@APRC-P3-Tel Here are the replies of your questions:

1.After importing, Is their a way for users themselves to change their wifi passwords ?

 After we import the user to the system, the client cannot change the wifi password unless they change the password on the system. 

2. All user passwords  are visible to operator and administrator of Omada System. He can export user info in clear text including password, View it on screen etc. Is this not a security flaw ? why not admin/operator limited to just resetting of the password to some default/random value  and not see it or export it with password ?

Now only the administrator has the permission to add/delete the users. For the operator, who only has the permission to view the information. 

3. Can we have a facility of storing the email addresses in this database (if name and telephone no is there) and have a feature to mail the password to their email address and received by out of band means like another wifi network or cellular  (or even SMS)? Also if done, a forgot password feature for users at a later date ?

For now, password recovery via SMS and email is not yet supported. But your feedback is very useful, we will consider it. 

4. Also can a given Portal support  two authentication method with user selecting which method to use. Like support  user-password as default and SMS-authentication/Voucher as fallback/alternative. Currently this seems to be strictly 1-1 mapping.

We have 8 kinds of portal and they can almost meet all requirements. For your suggestion, can you tell us why you want one portal with two authentication method?

5. Is it feasible to do any bulk change modification to this table for fields such as rate limit & traffic limit. Now it can be done manually one by one and not sure if we can replce user info with a bulk import that overwrites existing user configuration.

This suggestion is very useful. We will consider it. 

@forrest: Clarifications/answers inline ...

forrest wrote

@APRC-P3-Tel Here are the replies of your questions:

 

1.After importing, Is their a way for users themselves to change their wifi passwords ?

 After we import the user to the system, the client cannot change the wifi password unless they change the password on the system. 

 

The root of the requirement, is for users to manage the passwords of their own accounts, just as they would for Gmail, Yahoo, etc. We wanted therefore to set up a free authentication rule, where we put the IP/Mac of Controller and let each user access his account (when he connects to our network) and change/update *only selected information like Password, Name, Telephone No., etc  [An *additional field for storing a URL to additional info may be useful here]

 

2. All user passwords  are visible to operator and administrator of Omada System. He can export user info in clear text including password, View it on screen etc. Is this not a security flaw ? why not admin/operator limited to just resetting of the password to some default/random value  and not see it or export it with password ?

Now only the administrator has the permission to add/delete the users. For the operator, who only has the permission to view the information. 

The requirement is that administrator is not able to see user passwords.  In india,  their is a regulatory requirement, that seems to suggest one Wifi Internet user's password cannot be used by another and if we expose this password to admins and operators, we open a small door where a user  committing cyber crime, when caught, can deflect attention by saying that the device used to commit cyber crime does not belomg tohim, but to the operators and admins. 

 

3. Can we have a facility of storing the email addresses in this database (if name and telephone no is there) and have a feature to mail the password to their email address and received by out of band means like another wifi network or cellular  (or even SMS)? Also if done, a forgot password feature for users at a later date ?

For now, password recovery via SMS and email is not yet supported. But your feedback is very useful, we will consider it. 

 

The clarification to point 1, should give a potential reason on why we would want this. We want users to manage their  own passwords, not admins. And once users manage, few are going to lose them also.  Admins can only reset to some random/defined value and that reset operation will be logged. Communication of reset/changed password  would be preferred by email. 

 

4. Also can a given Portal support  two authentication method with user selecting which method to use. Like support  user-password as default and SMS-authentication/Voucher as fallback/alternative. Currently this seems to be strictly 1-1 mapping.

We have 8 kinds of portal and they can almost meet all requirements. For your suggestion, can you tell us why you want one portal with two authentication method?

 

We have these classes of *human users on our community Wifi

 

(a) Residents - Medium/Long term users who may staty 24x7 in facility

(b) Staff or Workers - They come daily and go daily. They will use for 8-10 hours 

(c) Visitors - Taxi Drivers, Guests who come and goafter few minutes/hours. Short_tyerm Transient users.

 

We have seperate SSID (shortly seperate VLAN), seperate poretal, seperate QoS, for each of (a)-(c). However have implemented SMS authentication for all 3 classes based on regulatory demand. But for (a) and (b), since they are frequent/regular users, we think (username, password) authentication is also desirable (and this is permitted by regulatory with additional KYC requirements), since SMS delivery is not reliable in many locations [no cellular signal].  Also some user need special QoS. Therefore we want to explore if we an have backup to SMS authentication like (username, password) method, but both operating at same time and let user select method of authentication among them.

 

 

5. Is it feasible to do any bulk change modification to this table for fields such as rate limit & traffic limit. Now it can be done manually one by one and not sure if we can replce user info with a bulk import that overwrites existing user configuration.

This suggestion is very useful. We will consider it. 

 

 

@forrest 

@R1D2 : An external portal server will not solve many the issues due to which we are trying to ask for some small requirements. SMS will still not come, wherever cellular is weak. And password encryption/safety/security/managment is something which should be independent of any *culture or *political enviroment.

Infact it may open a new can of integration, stability and maturity worms, if we try integrating an external portal application which is not tried/tested and widely used in the community. I fear a series of  otherwise avoidable troubles on that route. Omada Hotspot Portal Server seems to be meeting 99%  of what we would love to have, is stable and just works. So we try some luck here with the remaining 1% ;-))

What data we want to collect

======================

On the issue of personal data collection, currently the design requirements we are converging to is:

(1) Identify each user (even if he uses multiple devices) absoluetely without ifs & buts - that is why stress is being laid on password ecryption, invisibility to operators/admins, slef help and care, etc. This is not a unique thing. Any OS we use (windows, linux, unix. etc) has this feature. Any Cloud service we use (Google, Apple, Microsoft, others) has this too. Why a Hotspot Application Server should be *any different ? Why we need to make admin/operator a "caesar's wife" actor ?

(2) Logging info - This has some personal details

      (a) The User's mobile no. (in case of SMS authentication) or Identity (in case of user-password) that he uses to authenticate his device with our network - This is already availablle in "Hotspot Manager -> Guest" page, but absent in Logs. It would be great if Mac Address and mobile No. can be put in Logs also when user joins (this type of log is ther but it puts a long cryptic hostname for many android device, which is not so useful)

      (b)  The User's device Mac-Address - Implemented same as (a) 

      (c)) The User 's device IP-Address when he connects to our network 

      (d) When he connected, when he disconncted (or DHCP lease expired) with the device

      (e) And lastly to store such records for *atleast 1 year - I have  used syslog server per your suggestion to send and archive these records on a seperate storage server and that can be scaled upto store even for 100 years, irrspective of whether controller stores for 1 month or 1 year.

We want (a) -(b) from Portal Application server, while (c) and (d) are Layer-3 Router requirements. 

We have no regulatory or personal requirement to track user session activity (what apps he uses, what sites he visits, etc).  We think its unethical to do so also and will not do even if we have to shelve the project. Beause of prevalence/popularity of Mobile/Desktop VPN apps, we cannot collect also, in many cases. 

Some cultures may think  that (2) (a)-(e) is invasive of user privacy, while others may think its tolerable in the interest of personal online safey or national security. Maybe it will take another century to settle privacy vs Surveillance debate. Till that time maybe we can keep such things configurable (auto/manual) or build time firmware specific switches, rather than ignore it altogether.

How we use this personal information

=============================

Law enforcement will come to us with the Public IP address of our Broadband ISP's Router, date and time, if a cyber crime gets committed using our network. They will carry a warrant asking us to turn over all the log and other records (such as CCTV footage) [that we are looking to collect in (2)(a) -(e)]to them or want access to this data. Through this data, they would lin-turn like to identify

(i) Either the pepetuating device (mac) and user (mobile no.)  [BETTER] or

(ii) a list of suspect devices and users on that day and around time for for further investigation

If law enforcement get neither (i) or (ii), it puts us on a sticky soil. The regulator can take cognizance of such things, step in if matter becomes serious at our or other site and further put breaks on Public owned Public Wifi,  and esspecially if they could get big telecom operators to satsify their needs with better equipment. In the end, impact will also go to OEMs like TP-link, who may lose a potentially growing market opportunity. Hospitality, Retail, Healthcare etc  which also deploy carrier indepenent Public Wifi in many cases will have same requirements which they will not be able to satisfy and infact are more vulnerable than us (we are a big residential community) being really public spaces.

Also  as a policy we do not mine this stored personal data at all for anything, and in most likely we will delete records older than 1 year.

R1D2 wrote

@APRC-P3-Tel, I think you can easily implement any such requirements by using an External Portal in Omada Controller. An External Portal allows you to query all data you require from the users, it allows you to store MAC addresses, IP addresses, names, phone numbers etc. It also allows you to encrypt passwords for user accounts. It further allows you to implement any scheme of authentication. So, why not use this function for your local requirements?

 

Note also that in other regions it might be forbidden to acquire any personal data (e.g. in the EU). It's also a violation of the GDPR law to track users. Authorities are even not allowed to demand certain authentication schemes from WiFi providers. Users here are entitled by law to anonymously use comunication facilities. Law enforcement can only request log records if a judge demands this data and there are strict requirements what providers are allowed to record at all for user sessions.

 

What in India is required by law might be forbidden to record at all in the EU by law. Thus, such contradictory requirements can be implemented only for certain regions.

 

External Portals help to solve this problem.