I'm the administrator of a growing corporate network and we will shortly be providing guest WIFI access.
I have been to various places before where the receptionist has generated a random username and password which has then given me access to the web for a period of hours. If I wanted more, I'd go back to reception and they'd repeat the process.
I would like to implement a similar process for our network.
Does anyone have any pointers towards suppliers/makers of the software that could do this? I imagine it'd run on a Windows PC, and connect to our Active Directory in order to create such accounts under the appropriate policy.
Thanks.
A lot of routers have the ability to communicate to a Radius server. What you would need is a front end to generate usernames and passwords for the radius server that expire after X amount of time.
Related
I wish to create a functionality that is very similar to facebook or pokerstars if you have used them before. Basically the apps require the user to login and their information can be accessed from both browsers and native and web apps.
How can I go about achieving this? Please advice on what services to research on to accomplish this. To my current understanding. I would be creating the website in html and php and creating a webservice using RESTful protocols and hosting them on amazon aws servers. I can then connect to these servers in the native apps? I am not very clear on how the native apps will interact with the servers
If you know of any particular protocol or a better server hosting service please let me know.
If I'm interpreting your question correctly, you are looking for something like this:
The user starts either your browser app or your native app (perhaps a mobile app)
Since the user does not have an account yet, you present them with the appropriate dialog to create said account.
You then ask the "Identity Service" to create a profile for that user
The identity service returns a token for access
This is something we do in the mobile network industry all the time. Technically, we have TAC/ACS or HSS profile services, but in either case, it's the same thing -- a dedicated service and network process that:
Accepts connections from various clients (web, mobile, desktop...)
Has various primitives along the database CRUD (Create, Read, Update, Delete) model
Answers requests the database
If you want a pre-configured solution, you could just use any networked database with a RESTstyle connector for example (MongoDB maybe?) But you could also just through this in a process that talks to a NoSQL or SQLLite database. The end result is the same.
For commercial solutions, I might like at OpenStack as you can run your code on it and they have identity brokers you might be able to CoOpt.
Personally, I'd just have a datastore running on a cloud somewhere like Amazon's EC2 which answers RESTful requests such as:
Create a user with a given profile set, return a unique token
Delete a user given a token
Update elements of the profile for a given token
I'm leaving out the necessary things like security here, but you get the idea.
This also has the advantage that you can have a single identity service for all of your applications/application services. The specifics for a given application element are just sub-fields in the profile. This gives you, not only a common identity broker for web, desktop and mobile, but a single-sign-on for all your applications. The user signs in once and is authenticated for everything you have. Moving from site to site, now just became seamless.
Lastly, you place your identity management, backup, security token management, etc OUTSIDE of your application. If you later want to add Google Authenticator for second-factor authentication, you don't have to add it to every application you have.
I should also add that you don't want to keep the identity database on the direct internet connection point. Someone could make your life difficult and get ahold it later on. Rather, you want your identity server to have a private link to it. Then do something like this:
When the account is created, don't store passwords, store hashes -- much safer
Have your application (web or otherwise) compute a key as the login
In this case, the user might enter a username and password, but the application or website would convert it into a token. THAT is what you send across.
Next, using that token (and suitable security magic), use THAT as the owner key
Send that key to the datastore and retrieve any needed values
Encrypt them back into a blob with the token
Send the block
THe application decrypts the blob to get at values
Why do we do this?
First, if someone were to try to get at your identity database, there's nothing useful. It contains only opaque tokens for logins, and blobs of encrypted data. Go ahead -- take the database. We don't care.
Second, sniffing the transport gets an attacker nothing -- again, it's all encrypted blobs.
This means later on, when you have five applications using the broker, and someone hacks the network and steals the database, you don't care, because your users never gave out logins and passwords in the first place, and even if they did, the data itself is garbage to anyone without the user key.
Does this help?
I have the following scenario.
At my company we use Oracle 11g. The authentication on the frontend is using database users. So, every user of the frontend has a his own user account in the database system.
This implies that they have the ability to connect directly to the database, if they know the IP address, port, etc,. Of course, this is not considered a security concern because our strict managment of roles and privileges. This also implies that when a new user is added our DBA have to create the user and assing the proper roles and privileges.
Until now, our frontend is accesed only by our internal users. However, We are planning to add the capability for our external users can login in our frontend.
Our estimation is about 750,000 external users with annual increments of 50,000. This users are supposed to access our system three or four times per year.
The question we have is how to grant access to this users.
By using our already implemented authentication system. Every user has his own database user account.
Generating an authentication system for external users only. Like most of the CMS's in the market, with tables as an ACL (Access Control List) for users, passwords and roles for our 750,000 external users.
My main concern is to have +750,000 database user accounts that will be unused most of the time and eventually could make a mess with our internal users.
Someone have a similiar experience with this amount of users and how did you deal with it?
Best regards.
Off the top of my head..
Make sure that whatever outward facing boxes are few in number.
For the boxes that can connect to the database - make them purely
authentication or get/put for the data. don't run the web server on the databases or on the same LAN segment.
If possible encrypt communications from the client to the database so that if any of your intermediate hops get rooted they'll only see junk.
Use a firewall to ensure that only the bare minimum can get through.
For validating authentication, don't let their 'real' password get off the web server. Keep it hashed, San Diego!
If I had a poll on my site, and I didn't want to require a registration to vote, but I only wanted each visit one, how might I do this?
Let's say a visitor from IP 123.34.243.57 visits the site and votes. Would it then be safe to disallow anyone from 123.34.243.* from voting? Is this a good strategy?
What's another one?
This is a fundamental challenge with all voting sites on the Internet, and you're just breaking the surface of the problem.
The way you've phrased it, you "only want to allow each visit one [vote]" indicates that you want to allow them to vote once each time they open their browser and go to the site. I don't think this is really what you seek.
I suspect what you want is that a given individual Person can vote only once ever (per survey, maybe).
The problem is, once you've framed the question properly, the problem becomes much more clear. You're not trying to identify an Internet node (IP address), visit (session cookie), browser instance (persistent cookie), or computer (difficult also to identify).
You can use techniques with Cookies, and they were suitably for a typical user. Subverting this technique is as easy as
- Clearing your cookies in the browser,
- Disallowing cookies in the browser,
- Opening another browser,
- Walking to another computer,
- Using an anonimizer,
- ... endless other ways.
You can do validation by e-mail address, but you indicated you don't want to do registration, so I don't believe that solves you problem either.
If you really need to identify a unique user for a voting system, you'll need to have some authority who's willing to vouch for the identity of any given user, or only allow the software to be accessed from a trusted platform.
The first technique requires registration (and often a costly and time-consuming registration at that), that verifies the actual legal name and location of the individual. Then, using Public Key Infrastructure (aka Digital Certificates), you can identify an individual person based on the credentials he supplies.
The second technique, requiring a trusted platform, relies on the hardware following certain pre-determined behavior. You could, for example, create a voting site that works through the XBox 360 or iPhone. You would create an app that is installed to one of those devices. Based on the way the platform is protected, you could use uniqueness characteristics, such as the hardware address or Live ID on the XBox 360 or the hardware address or telephone number on the iPhone, to get general assurance that the user is the same one who has visited before. Because you have control over the application and the user specifically does not, due to the nature of the trusted platform, you have reasonable assurance that most users will not be able to subvert the intent of the application.
I suspect this is a long-winded way of saying you can do it, but it's a far from easy problem to solve.
Consider political elections and how much resources and energy goes into making those fair and anonymous, and still it's a very challenging problem.
Using the public IP for this would probably be a bad idea. Unique visitors from the same corporate LAN would all look like one user if you use this approach.
Perhaps cookies? I believe that is what most sites use.
Combine with some sort of monitoring, automatic or manually (for instance log file analysis). Be suspicious of traffic patterns that indicate a script.
No, you can't use IP address or IP spans to identify unique users. For several reasons:
Stopping a whole span will stop users who haven't voted.
People who get an IP adress dynamically will get a different IP address later.
People in a local network (like a big company) share the same public IP address.
You could use a cookie to flag who has voted. That will be a lot better as it doesn't hit as blindly, but it's of course not completely accurate as people can clear the cookies and browse with more than one browser.
To make a completely accurate identification of the users so that you are really sure that noone votes more than once, you need a login for the users. Well, with the exception for the fact that people could create more than one account of course...
block a ip range is not a good strategy, you can have 2 option to indentify the already voted user, their IP and cookie. after they voted, set a cookie and don't allow them to vote again.
they can clear cookie and change the IP, but it's acceptable for anonymous voting, if you want a better strategy, let's them register for voting
You should block just that particular IP, not the whole IP range!
If you don't have a registration, this is the best solution, but not for users!
You can prevent someone from voting multiple times. but you also may block some other users from voting and that's because of NAT.
Network Address Translation (or NAT) allows multiple users use a single IP to access internet.
But this is OK because NAT is not used heavily and few users will be disallowed from voting.
However, cookies is not the good solution. because the user can easily erase the browser cookies and vote again. Even worse, he/she can write a script to vote automatically many times!
I have 20 stores in different locations that want to login to a punch in(Employee/Hours) application. How can I force them all 20 stores to login from the same computer/store every day? I am working with .net but other solutions maybe consider.
Thanks
Some possible answers based on interpretation of question:
1) Lock the program down based on the computer's MAC address at each location. This would allow you to only allow the program to run on the one computer at each location.
2) If you want only the stores to connect to your server, then you can restrict access to only specific IP address using routers and firewalls.
This is not a technical question. How do small organizations keep sensitive information that must be shared among several individuals safe, such as root passwords to production servers? Not all people that need to have access work in the same location.. new passwords can be distributed by phone, but what rules should be enforced for team members in the storing of the passwords?
UPDATE: this question is not about the proper usage of root passwords -- that was just meant as an example. Maybe a better example would be the SSL passphrase or any other password that must be shared among people performing administrative tasks. The fact is, root passwords and the like need to be generated and stored and usually more than one person needs to have access, sometimes those people work in different locations. The question is about storage protocols. Thanks.
You shouldn't be handing out (or using) root passwords to any servers, production or otherwise. You shouldn't be sharing passwords.
People should log in as themselves (authentication) with their own user ids passwords; that's one half of the picture.
When properly logged in they should be given rights (the authorization side of the picture) as appropriate. You can use things like sudo for general OS purposes, and the rights mechanisms inside databases, etc.
These are two separate issues. Don't cross the streams!
I personally recommend to people facing similar problems to use something like keepass or roboform to store passwords. These programs encrypt your passwords on a thumbdrive using a master password that the individual remembers, so that they need only remember the master password. In the event that someone looses their thumbdrive, they will have a window of time in which they can report the compromised thumbdrive, and allow you to change passwords. It will take a little bit of time, depending on the master password's strength, before the person who stole the thumb drive would be able to brute force the master password to get at all the other stored passwords.
Additionally, avoid having any account shared by more than 3 people, if at all! Instead, consider creating each individual an account with equivalent access. If a malicious employee has access to an account which they know is shared, it might be more tempting for them to do malicious things since they know you could not hold them accountable, since it could have been any of several people sharing the account.
This also means you don't have to change the password every time someone quits. Instead, you just disable/delete their account. So although you have more accounts to manage, you have less overhead when someone leaves since you don't have to notify everyone of a changed password.
Edit: Oh Roboform also has a online password sync service over SSL. So you could just have people retrieve passwords via syncing. It's kinda cool once you get used to it.
With the advent of sudo we seldom need to use a root password any more. In my old shop, the root password was written on a card, sealed in an envelope, and locked in a drawer in the sysadmins' area. Those who needed to know had keys to the drawer.
Anybody opening the envelope was required to change the password and put the new password in a new sealed envelope. The envelope was not opened often.
This system is probably really bad professional practice, but in a small shop where everybody knew everybody, it worked well.
In a prototype & R&D lab where I formerly worked, there were 'standard' lab passwords for things like root, administrative access to consoles, switches, etc. These are simple, easy to remember, and shared verbally with anyone who needed them. In general, if you could physically get into the lab, you were authorized to have these passwords.
In the manufacturing facility, new systems were built and configured for customers. The customer got to choose all the passwords, and they were printed on a set of forms that were attached to the rack with the systems. Remote access was provided as required, and the passwords were sent in an e-mail, or given over the phone. It was fully expected that the customer would change these passwords as soon as the system was delivered to them.
For the IT & Production labs, almost no one had root access. Almost everyone did have sudo access with somewhere between no limits and only the ability to mount virtual filesystems...depending on the person and the system. It was very rare to get sudo access to launch a shell as root. This left a very clear log trail of all the commands you ran as root. That log was used to tar & feather more than one person over the years.
At a help desk / support role I had many years ago, each tool expert picked their own administrative passwords. These were recorded in an envelop that was locked in a safe in the machine room. If someone needed admin access, they could open the envelop, read the password, and note in the log that they knew the password and then re-seal the password in the envelop. It was up to the tool owner to decide if the password needed to be changed. This system was used for more than 5 years...and in one case actually helped the project to survive the "bus test" (heart attack) for one team member.
Different standards for different kinds of systems and labs. That is reasonable. I find that when passwords need to be shard, it is best if the password is simple, short, and communicated verbally (either in person or over the phone). I find that the only password that should never be shared is the one for my personal account. Any root/admin/tool specific passwords should be backed up in at least one other head...if not recorded in some manner.
you can use a program like anypasswordpro to share passwords. It is encrypted and has levels of access :)
Be realistic. Whether you like it or not, people in small teams are going to write passwords on sticky notes, IM them, or be tempted to email them, especially when they perceive no threat.
One measure I've found useful with small groups is to establish an obfuscation protocol.
For example, all passwords communicated or stored via voicemail, email, IM, or paper will have
1) the order of their characters reversed
2) a random character or word placed in between each password character
3) phonetically pronounced password characters.
For example:
Password: VMaccp#ss1
Obfuscated: one 2 es df es 23 at sd pee fd see dfs see fxz ay df EM sd VEE
The key is to establish some kind of encoding that is virtually impossible for someone to figure out without knowing the protocol, which is easy to remember.
Keep in mind this is for small groups without life-or-death security. Obviously for larger groups or those protecting extremely sensitive financial data stronger more cumbersome measures are appropriate.