I'm trying to use Connman to manage the WiFi connection of my embedded system because it handles automagically any type of protection.
In interactive mode it's very simple:
connmanctl
agent on
scan wifi
services
connect
enter password if requested
On my system, the user enters the WiFi credentials (SSID, password) using a remote (web) application. Then I would use this information to setup connman using a script.
The goal is to avoid the user to select which type of protection is going to setup. I mean, most users just enter SSID/password but they don't know if it is a WPA-PSK or WEP connection.
I'm reading throught the documentation, but I'm not sure which is the correct approach:
a config file: http://git.kernel.org/cgit/network/connman/connman.git/tree/doc/config-format.txt
but as far as I understand I need to specify the type of the security:
Security: The security type of the network. Possible values are 'psk'
(WPA/WPA2 PSK), 'ieee8021x' (WPA EAP), 'none' and 'wep'. When not set,
the default value is 'ieee8021x' if an EAP type is configured, 'psk'
if a passphrase is present and 'none' otherwise.
It seems 'wep' is not handled if the field is omitted.
dbus-api: http://git.kernel.org/cgit/network/connman/connman.git/tree/doc/manager-api.txt
Here I understand it needs an 'agent' to feed the passphrase, thus I'm afraid I cannot send it programmatically.
Do you have any recommendation about?
Related
I am trying to configure JDBC but kept getting the same error I am getting using snowsql:
250001 (08001): Failed to connect to DB. Verify the account name is correct: JG3409.canada-central.azure.snowflakecomputing.com:443. 000403: 403: HTTP 403: Forbidden
If the error message is unclear, enable logging using -o log_level=DEBUG and see the log to find out the cause. Contact support for further help.
Goodbye!
I have configured the config file, and I have double checked the account, company, region, reset password to only use alphanumeric.
I have used both forms of the URL
The only possibility is that I am using a trial account, but I can't imagine that this would limit external non-browser connections?
I use a simple user/password, I have whitelisted my IP and I don't have a problem with a proxy or a firewall. I can successfully connect using a browser.. using:
https://app.snowflake.com/canada-central.azure/jg63409
Important contents of the config file:
[connections]
accountname=JG3409
#accountname=uegxydq-pz20606
region=canada-central.azure
username=ASHSNOWFLAKE
any ideas?
Your account is not JG3409 but JG63409 based on this link:
https://app.snowflake.com/canada-central.azure/jg63409
Try in your browser:
https://jg63409.canada-central.azure.snowflakecomputing.com
I found out using snowcd that my computer could not connect via my home router.
When I used my personal hotspot on my (5G) phone, snowcd passed all the tests immediately. The problem then arose how to adjust the network security policy to allow a CIDR block of network addresses through since my phone uses a new address every time I connect, and I can't edit the policy to allow my phone while connected via my phone (for obvious reasons)
Catch 22
123.45.0.0/16 is not accepted in the new Snowflake UI, and 0.0.0.0 doesn't work for me, but the documentation gave me a clue.. the new UI doesn't separate by commas, so I switched to the old UI and voila!
Incidentally the OLD UI uses the same URL as SnowSQL so I picked up my error in my account number there as well (although I should have seen it earlier).
Diabolical but thanks #Sergiu too!
I need to generate and store a sensitive file (assume that it is not a traditional PKCS format) private key and keep it accessible to the running service.
Normally, when running as a service account (AD User), I would store the file under the user's profile, and then let standard Windows security handle this.
Outside of the CryptoAPI, where in the file system should I store this private key?
Using DPAPI, you can either use current user credentials or either the LocalMachine 'creds'.
LocalMachine will make all users on the computer able to Unprotect the data (still a solution though... if you trust every user on this computer).
Or, you can use impersonation to get the current user & do your stuff.
When using LogonUser() with LOGON32_LOGON_NETWORK to validate a user's Windows login and password, it does not seem to cause their account to be locked even if the wrong password is checked more times than the user's security policy allows.
There is a similar question:
Incorrect password passed to LogonUser() but the Active Directory account is not locked as expected
But in their case, they were using LOGON32_LOGON_INTERACTIVE instead.
In my case, the domain controller is available to authenticate the logon, but it is not clear from the documentation whether using LOGON32_LOGON_NETWORK means it does not authenticate with the domain controller, only that it will not cache the credentials if they are correct.
What I'm looking for is a policy setting that will lock a Windows domain account if LogonUser() is used with the wrong password too many times.
EDIT: Additional information to help clarify the situation.
When calling LoginUser() on my XE2 development machine with the correct domain\user but incorrect password, the result is false. Calling SysUtils.SysErrorMessage(System.GetLastError) gives me:
The operation completed successfully
The same test performed on any of the machines at the client site shows:
Logon failure: unknown user name or bad password
Continuing the test on any of their machines eventually has it reporting:
The referenced account is currently locked out and may not be logged on to
What I am trying to determine is why that client is behaving differently, as we'd like to have systems on our domain also lock accounts. Perhaps it is a property of the Windows account?
The policy setting you are looking for is the Account Lockout Threshold.
I don't believe this has anything what-so-ever to do with the fact that Delphi is the language involved in calling the API. This is purely a Windows API / security policy question.
Is is possible to authorize users at a machine level. For example, only when using authorized computers (my personal laptop or other managers' pcs) can one get access to the admin page? Any other computers should either get a denial of access message or something else. Authorized computer may still provide their own admin username and password in case people could fake a machine's identity, maybe. I'm not a security expert though.
Correct me if I misunderstand, but you are asking to only allow visitors on specific machines to access your website?
Jumping right into a solution here. The first question is how do you know which machines are "manager's" machines? Do you have a list of their IP addresses? Do you have some other ID on them?
If you have their IP addresses, then IP Whitelist them, and block all other ip addresses.
If you do not have their IP address, then you are limited. There is no machine ID that can be accessed through a web browser, so you'll need to create your own ID by setting a long lived cookie and a registration process.
Since you already have a login process, this next part is fairly easy. You've used this solution before. When you sign in to google mail and click "remember me" and don't need to sign in the next time your computer restarts, google has basically marked (set a cookie) your machine as yours.
Now, if you want to get super fancy, enterprises have NAC setup. Every system is identified before being allowed to connect to the network. Certain systems are given more access than others. For example, at a software development company, engineers may be given access to a production network while sales staff is not. When they connect, sales staff are move to a restricted vlan after identifying who they are and who the machine belongs to. If that were the case for your company, then you would whitelist an entire subnet block.
Last point. Chase bank uses the machine cookie concept like so: The first time you login they ask your username and password. Then the send a code to your phone or some third-party channel. After you enter the code, the set a machine cookie (same old cookie). The next time you login, they ask for username and password, then look for the machine cookie. If the machine cookie is there, then they don't make you enter the code again.
You could make that your registration process, except you provide the manager with a code they can enter. I don't think you want to get much more complex than a static password to register the machine, but if you did, you can generate one time tokens following the spec in rfc 4226.
You can't restrict access to specific computing device (as there are many types of devices used and there's no universal thing to bind to) but depending on your application design you still can solve your problem. You need to bind not to computer, but to other hardware device which is not possible to duplicate.
One of such devices is a hardware cryptotoken or cryptocard with the certificate and a private key in it. The user plugs the device to USB or to card reader respectively, then he authenticates on the server using the certificate and private key stored on this device). Client-side authentication using certificates is a large but well-known topic so I don't discuss it here.
While it's possible to move the cryptographic device to another computer system, it's not possible to duplicate it or extract the private key from it. So you can (with certain high level of reliability) assume that there exists only one copy of the private key and it's stored on certain particular device.
Of course you would need to create another certificate for each device, but this is not a problem - the only purpose of these certificates is to be accepted by the server, so the server can issue new certificates when needed.
I need to establish a HTTPS 2-way SSL connection from my iPhone application to the customer's server.
However I don't see any secure way to deliver the client side certificates to the application (it's an e-banking app, so security is really an issue).
From what I have found so far the only way that the app would be able to access the certificate is to provide it pre-bundeled with the application itself, or expose an URL from which it could be fetched (IPhone app with SSL client certs).
The thing is that neither of this two ways prevent some third party to get the certificate, which if accepted as a risk eliminates the need for 2-way SSL (since anyone can have the client certificate).
The whole security protocol should look like this:
- HTTPS 2-way SSL to authenticate the application
- OTP (token) based user registration (client side key pair generated at this step)
- SOAP / WSS XML-Signature (requests signed by the keys generated earlier)
Any idea on how to establish the first layer of security (HTTPS) ?
Ok, so to answer my own question...
It turned out that the security has no fixed scale of measurement.
The security requirements are satisfied as long as the price for braking the system is significantly above the prize that one would get for doing so.
In my situation we are talking about e-banking system, but with somewhat low monthly limits (couple of thousands USD).
As I mentioned in my question there would be another layer of security above the HTTPS which will feature WSS XML-Signatures. The process of registering the user and accepting the his public key is also done in several steps. In the first step the user sends his telephone number together with a cod retrieved somehow from my client. Then an SMS is sent to the user with a confirmation code. The user enters the confirmation code into a OTP calculator that would produce OTP code which will identify the user. Then the public key is sent to the server together with the OTP code. From here on every request would be signed by the private counterpart of the public key sent to the server earlier.
So the biggest weakness for the whole process is that of someone reverse engineers the application and retrieves the client certificate used for the SLL. The only problem arising from this is that someone might observe users' transactions. However in order for someone to make a transaction he would need the user's private key, which is generated, encrypted and stored into the keychain. And the price for braking this security level is VERY HIGH.
We will additionally think on how to protect the users' data on a higher level (e.g. using WSS Encryption), but for the start I thing we are good with the current solution.
any opinion ?
regards
https doesn't really work this way. In a nutshell, you attach to a secure server where the certificates are signed by a well known authority.
If you use Apples (iPhone) classes for this, they will only accept 'good' certificates. By good, I mean what Apple deems as acceptable. If you don't use them (there are alternatives in the SDK), you won't be able to connect (except, maybe, in the case where you have an 'Enterprise' developers license - but I can't say that with 100% certainty as I haven't looked enough at this license to be sure)
To continue, use your https connection to your correctly signed website and then institute some sort of login with a built in username/password, or challenge/response based upon the unique ID of the iPhone (for example) and exchange keys using that connection.
Note that this means that your application will have to query for new certificates at (each connection/every X connections/every month/application specified intervals) to keep them up to date. You can then use these certificates to connect to the more secure server.
[edit]
Check this post - may have more information about what you're asking to do
[/edit]
[edit2]
Please note that the request is iphone, not OSX - app store approval is an issue
[/edit2]