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.
Related
I have an interesting problem. Let's say we have a user, Bob, who logs in to some service. How can that service prove Bob's identity, assuming Bob actively wants others to try and impersonate him? i.e. How can we be sure that the user logging in is indeed Bob?
Using the MAC/IP address of Bob wouldn't work as these can be easily spoofed.
A username/password as means of authentication wouldn't work since Bob could just give these credentials to anyone.
A public-key system (e.g. using RSA for signing) wouldn't work as Bob could just share his private key with anyone.
What I essentially need is Bob to have some proof of ID that he cannot share (or is at least hard for someone else to replicate, given all information that Bob has).
Edit (in case this is useful): I'm working with an iOS app (Bob) and a Python web server (the service).
Alternatives:
Hardware token that the user must present during authentication like a usb token or a cryptographic smartcard
Biometrics can not be shared. For example fingerprint/voice/ear/iris recognition. In some cases you will need a reader (note fingerprint biometric data is not available in mobile devices), and you have to work with confidence ranges and huge databases for comparison. An ID is never 100% reliable.
public key cryptographic systems that manage non-extractable keys. The cryptographic provider in user side allow to generate or import keys that can be marked as non extractable, and can not be exported outside. e.g WebCryptographyApi, AndroidKeyStore, iOS KeyChain or Window Keystore. During user registration, is generated a cryptographic key pair, public and private. The public is sent to server associated with user account, and private is stored securely. Authentication is done with a digital signature using the private key.
See FIDO UAF (Universal authentication Framework) and FIDO U2F(Universal second factor)
https://fidoalliance.org/about/what-is-fido/
About iOS KeyChain, it allows to mark a key as non extractable. See Apple Documentation
Important
If you do not set the CSSM_KEYATTR_EXTRACTABLE bit, you cannot extract the imported key from the keychain in any form, including in wrapped form.
Take a look also to Store and retrieve private key from Mac keychain programatically
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.
I'm just getting started with D2L and am running into problems.
On the "Getting Started" page, I have completed the first three steps:
1) Acquire an App Key/ID pair from D2L - I have received the App ID and App Key
2) Create a test account in your host LMS - I have created a new user account with the administrator role for testing
3) Choose a client library to work with - I am using the PHP SDK
4) Authenticate with your LMS - This is where I'm running into trouble.
When I use the Getting Started sample:
http://samples.valence.desire2learn.com/samples/GettingStartedSample/
And enter my host, app ID and app key and hit on the "Authenticate" button, I get a "This application is not authorized on this LMS instance. Ask your administrator to authorize this application" error.
I am an administrator on my D2L host and I'm not sure how to authorize my own app.
I have tried the following:
Navigating to the "Manage Extensibility" page because that's where D2L says my app should be located, but it isn't there.
Enabling the API (d2l.Security.Api.EnableApi) under the "DOME" page to no avail.
What am I doing wrong?
Based on your question and comments, there were two issues here:
First is that the list of App ID/Key pairs appropriate for your LMS get regularly fetched by your LMS from the D2L KeyTool service. The schedule for this fetching is once a day; accordingly, if the scheduled task isn't set up, or if your LMS isn't identifying itself properly to the KeyTool service, or if time hasn't yet elapsed after key granting to the next scheduled run of the task, the App won't yet be in your LMS' Manage Extensibility list. It sounds like you no longer have that issue.
Second is that the Valence Learning Framework APIs' authentication process (requesting and retrieving a set of user tokens for an LMS user) requires several LMS features to be properly set up: (a) the LMS must be configured to support Deep Linking, (b) the LMS must be set up to handle the ?target= parameter on incoming client URL requests, and curate that parameter throughout the user authentication process.
In cases where your LMS is not doing the user authentication but depending upon another, third-party IDP (like Shibboleth), any ?target= parameter passed into the login process must be taken care of by the IDP and properly handed back to the LMS after user authentication. In a situation where you have multiple redirections occurring during user authentication, this can involve successive generation of a target parameter, and each generation must re-URL-encode the previous request URL in its entirety (like sticking an envelope inside another envelope, inside yet another envelope).
If your LMS is not properly configured to support these two points, which you might not notice during other operations, then client calls to the Learning Framework APIs won't work because the calling client won't be able to fetch back a set of user tokens.
To solve the second of these issues, you may have to contact D2L's Customer Support desk -- they can verify, and adjust as necessary, the LMS configuration part of this authentication chain. If you're integrating your LMS with other third-party IDP components not administered or deployed by D2L, then you might also need to adjust their configurations: D2L can likely advise on what needs to be done there (curate the target parameter on URls), but cannot adjust the configuration for you in those cases.
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]
I'm trying to write a web application that would use Twitter via OAuth.
I run my local server as 'localhost', so I need the callback URL to be something like http://localhost/something/twitter.do but Twitter doesn't like that: Not a valid URL format
I'm probably going to do a lot of tests, but once I've approved my app with my username, I can't test again can I? Am I supposed to create multiple twitter accounts? Or can you remove an app and do it again?
You can use 127.0.0.1 instead of localhost.
You can authorize your app as many times as you like from the same twitter account without the necessity to revoke it. However, the authenticate action will only prompt for Allow/Deny once and all subsequent authenticate requests will just pass through until you revoke the privilege.
Twitter's "rate limiting" for API GET calls is based on IP address of the caller. So, you can test your app from your server, using the same IP address, and get (once approved) 15,000 API calls per hour. That means you can pound on your app with many different usernames, as long as your approved IP address remains the same.
When you send the e-mail to Twitter to ask for an increase to your rate limit, you can also ask for the increase to apply to your Twitter username too.
I believe Twitter requires you - if you need to change your IP address, or change the username that is using the app - to send in another request asking for the rate limit increase for that new IP address or username. But, in my experience, Twitter has been pretty quick at turning around these requests (maybe less than 48 hours?).
use like this
for Website :http://127.0.0.1
and for callback URL: http://127.0.0.1/home
or any of your page address like http://127.0.0.1/index
Have you tried creating your own caching mechanism? You can take the result of an initial query, cache it on thread local, and given an expiration time, refresh from Twitter. This would allow you to test your app against Twitter data without incurring call penalties.
There is also another solution (a workaround, rather) which requires you to edit your hosts file.
Here is how you do it on a linux box:
Open your /etc/hosts file as root. To do this, you can open a terminal and type something like sudo vi /etc/hosts.
Pick a non-existent domain to use as your local address, and add it to your hosts file. For example, you will need to add something similar to the following at the end.
127.0.0.1 localhost.cep # this domain name was accepted.
So, that's pretty much it. Pointing your browser to localhost.cep will now take you to your local server. Hope that helped :)
In answer to (1), see this thread, in particular episod's replies: https://dev.twitter.com/discussions/5749
It doesn't matter what callback URL you put in your app's management page on dev.twitter.com (as long as you don't use localhost). You provide the 'real' callback URL as part of your request for an OAuth token.
1.) Don't use localhost. That's not helpful. Why not stand up another server instance or get a testing vm slice from slicehost?
2.) You probably want a bunch of different user accounts and a couple different OAuth key/secret credentials for testing.
You were on the right track though: DO test revoking the app's credentials via your twitter account's connections setting. That should happen gracefully. You might want to store a status value alongside the access token information, so you can mark tokens as revoked.