I have a client that configures and deploys handheld scanners to remote locations. We have to pre-configure them to work on a local WiFi network. For these scanners we must manually configure SSID, Encrypted Password, and Encryption Type. We also need to know the Network/DHCP info (Subnet Mask, Default Gateway).
Unfortunately, we are often working with people who are not very tech savvy to provide us with their Wifi Information and they often provide us with incorrect or incomplete info.
So I'm wondering, could we write an App (or even better if there's already something that exists, though admittedly a long shot) that would prompt the User to enter the SSID and password and then would verify that it's connecting to the Access point and getting an IP Address... and then send us all of the configuration information via email (or http post? Or save it to a local file that the user could send to us?) so we can be certain we have the correct info before we ship the scanners?
Related
As the question says, i was wondering if there is a safe, and non really complex way to send credentials from an APP to an ESP32, in this moment i made an app that connect via bluetooth and send the credentials via serial and it works, but this way has 2 issues, 1) its not safe (not encrypted/secured data), 2) you have to ask in the application the credentials (SSID and password of the wifi) and i think it should exist some way that avoids asking for data that is already known by the smartphone. Any guidance on this topic will be welcome, thanks in advance.
all apps which are used to configure devices like IoT hardware and smart devices, ask the user to enter the wifi credentials when configuring the device, which is then transferred via Bluetooth or wifi connection,(the device acts as an access point, mobile with app connects to that devices' AP). you can save credentials one time and automate the process of sending them afterward.
I am pretty confused here trying to find a solution to this problem.
There is a wifi enabled micro controller and a client (android app), both connected to the same wifi network. The official android app sends some instructions to the microcontroller through GET params.
Now i want only and only the official app to be able to send meaningful data across. To prevent man-in-the-middle attack i can encrypt this data using asymmetric keys. The micro-controller will generate the public and private keys and give out the public key through the server when asked for.
But then comes the problem. Can't the attacker send data to the device (micro-controller) too if he knows the public key? The attacker can simply get the code of the app through reverse eng. and send meaningful data through his browser to the device.
Some limitations -
I cant make any sort of white-list on the device.
There is no internet connection. Just LAN available.
The device has no sense of time.
Some properties-
The devices have a unique 8 digit id. In scenario of multiple devices, the right one is targeted using this id. The devices' used IP address is mapped to this ID.
The android app (client) sends numeric strings in GET params for the devices to perform operations.
Can this be solved using a fool-proof method?
Thank you in advance.
I am using JuiceSSH for making SSH connections to my RaspberryPi whenever I want. What I need to do is swap the IP address value into the JuiceSSH configuration file with the IP address that will be sent by RaspberryPi in case of IP address change. I am thinking about using a google apps script in which I can get the new IP address value from the e-mail. But I don't know where the JuiceSSH app holds the configurations. And I do not also know whether I can manipulate any file into an android phone using a google apps script.
Google Apps Script cannot directly access any files except those in your Google Drive.
You may be able to empower a script to indirectly change the JuiseSSH config - if you can...
Figure out where it is.
Set up a web server on your phone to accept incoming POST operations.
See this LifeHacker blog.
When a valid POST is received, decode the payload and use it to update the local file.
There will be security issues with this!
Write your Google Apps Script
Monitor your email for a message about a change in your Raspberry PI's IP address.
Figure out how to track the phone's IP address!
POST the update to your phone.
retry periodically until the POST is successful (since the phone's connection is not reliable)
Another approach would be to have a Google Apps Script WebService serve up the current address of the device; then a program on the phone could periodically reach out to the service to find out the address, and update the file.
Of course, if you connected to your Raspberry PI using a name instead of an IP address, you wouldn't have to worry about any of this.
I am developing a application for mobile (iPhone and Android) maps based for a company. The company has deployed a wireless network to allow, by subscribing, internet access.
The idea of the mobile app is to give internet access only to that specific app to any ones that have it. In other words, company wants to allow to application to connect to this network.
My question is: is it possible to give access only to a specific application and what would be the most appropriate way? Is the app that "recognize" that network or network is in charge of give access to that specific app?
Any suggestion is very appreciated.
If you want to provide only app to connect to any network then you need to put some rules in IPTABLES in linux core (this needs your application to have root access) just like the firewall applications for android that monitors UIDs of applications accessing network
But you can do it the other way, implement some server calls that the particular network of the company will only be accessed through that particular app, Use some validation in http requests such as maintain a unique ID to differentiate your app/user that you can create during registration and during interacting with the network use the key for validation.
Generally speaking, a regular WiFi network won't have any facilities to allow a single application to access it. The mobile device OS associates itself with the WiFi network, and it will allow all applications to access it.
You could, however, use a proxy server that requires authentication. You could then build the authentication keys (for example, a client certificate) into the application such that only the application will be able to communicate through the proxy.
For WPA/WPA2, wpa_supplicant can give message of wrong-password when the connection fails in the HANDSHAKE procedure.
But when I try the WEP with a wrong password, the wpa_supplicant can get to the COMPLETED state without reporting any error.
I've searched on the internet and the only useful information I got is that someone said that iwconfigcan give the undecrypted packets in the Rx invalid crypt field.
But when I using WEP and I type iwconfig, the Rx invalid crypt field is 0.
I'm wondering how do those handsets judge wether the WEP password is wrong...
WEP network can of two types WEP-Open and WEP-Shared.
In the 802.11 standard, a device first Authenticates to the AP, and then Associates. The original designers intended that there would be a number of different Authentication methods to control who could use an AP.
In the 1999 version of the standard, 2 Authentication methods are defined: Open and Shared. In Open, any device can Authenticate to the AP. In Shared, only devices with the WEP key can successfully Authenticate.
The problem with Authenticate, is that were it is in the process of establishing connectivity, none of the higher-level protocols, like 802.1X can be run inside of the Authenticate 802.11 frames. So 802.11i does not use it, just uses Open Authenticate.
Shared Authenticate has a serious flaw, in that it is a simple challenge/response protocol. This design is very open to offline dictionary attacks. A WEP key would easily be exposed. Additionally, even in Open Authentication, a device that did not have the WEP key would not be able to communicate via the AP, as the AP would discard all data packets from the device.