I've written an application and I'd like to add a registration key/serial number to it (I'm big on minimum inconvinience - ala #4 at this Eric Sink article). My question is about where to store the "activation" once the application has been registered. As I understand it, I have a trade-off between storing the key in a public place, where all users can read it (but which requires admin rights to save there) and storing a per-user activation (but then each user on the computer will have to activate independantly). That gives me two choices:
Some user, with local admin rights, activates the product. The activation is stored in HKLM, in the program files folder, or somewhere else where all users can read it, and the product is activated for all users.
A user (with or without admin rights) activates the product. The activation is stored somewhere user-centric (per-user app.config, HKCU, etc). The plus is that the user doesn't have to be an admin. The downside is that if there are 6 users who use the computer, each has to activate the product. They can each re-use the same serial, but they still have to enter it.
Is this really the trade-off? If it is, what have others done? As a developer, I'm used to people being a local admin, but in the real-world, I don't expect many of my corporate users to be local admins, which makes me lean towards option 2. Are computers not shared often enough that I shouldn't be concerned?
Again, I'm not asking about how to physically register a computer - I'm not worried about it. I'm only going to checksum the key provided and give the go-ahead, as I want to be as non-invasive as possible.
I would recommend a solution that does not require admin rights. Lots of users, especially in shared environments, won't have those rights and won't be able to find anyone with them conveniently.
Also, going forward a few years, I think it will be getting increasingly unusual to have admin rights on the computer you are using, as the security situation improves.
Registry seems to be an okay solution for business software. At least at where I used to work, regular user will not be a local computer administrator, so each installation will require local administrator account. This is a good thing since it will lessen the headache of your support staff from people installing just about everything in your business computing environment. The trade off is of course, user will be pissed that they can't install stuff or have to contact support to do it, but hey... :)
Other stuffs:
USB / other type of dongle (ala old
3DMax)
plain old text file (ala
Garmin GPS software on mobile device)
Encode them / rewrite the key into
your binary or part of your binary
(did this trick back in th old DOS
days)
Store them in your own db via web (ala EverQuest / other MMORPG games)
Local key db (ala MathLab I think)
How about using the isolated storrage for you application?
You will have the ability to store this information on a mashiene level for your registration, and the configuration changes can be persisted on a user level.
We save our activation code to the registry for the current user (HKCU) we have had very little problems with it. Our customers run on everything from home computers to thin clients on cooperate networks.
If your software will be used in schools or other educational environments you need to provide some other method. It could be as simple as a separate registration application which will save to the activation for all users. Your software would have to do two registry lookups but that is a small price to pay.
In general, most computers are used by a single user (or multiple people still using the same user account). So a user based storage will work most of the time anyway.
However it's not either/or. There are folder locations that are writable by all users - such as the ProgramData folder. The key is to make the file readable/writable by Everyone so that you can verify the content regardless of the user.
DeployLX Licensing does this for non-secure license data so that it can be used by multiple users without an admin explicitly granting permission.
You should be consistent. If administrator rights were required to install the program, it's not out of line to require administrator rights to register it. Likewise if you somehow managed to install it without administrator rights then register it without too.
If you install and register in one step this won't be an issue.
Related
I am trying to enroll about a 100 systems in Intune. I want the user to be signed in as a standard user. I searched and found the only way to do this will be using AutoPilot. Thats is just not possible, It requires a factory reset device and a hardware hash for each device.
The other way they say is to run a Powershell script. That option won't work because I want only the one microsoft account on the system. Windows needs at least one Admin account.
I simply want the normal user to be a standard account and in case he needs admin privileges I can connect and type in cloud device administrator's credentials to give him access. However, I cannot find anyway to get this done, kind of hard to believe this is so difficult to do. Any suggestions?
I would like to secure folder, so that no one can cut or copy any file or contents of file without "secure" password (or happy to get rid of password bit as well, so no one can cut, copy or move any file or file contents from folder). Also, if all files and folders inside my root folder can be deleted after certain number of days, that will be great. This is to stop people from copying and distributing my files to others without my permission and folder contents to "expire" after certain number of days (e.g. 7 days).
Currently, I manually copy folder to other people's machine, so I do have physical access to their machines.
PS. I am happy to write a script as well, in case there is a way to execute script everytime I open the folder.
I understand, I can't stop people from stealing file contents by manually typing file contents to other file or taking photos of file contents, however I want to make it harder of them.
This is not a PowerShell issue, nor a solution provided by PowerShell. This is an data risk management issue as well as a reality check.
Don't get me wrong, you can write a scrip that encrypts data,
https://blogs.technet.microsoft.com/heyscriptingguy/2015/03/06/powertip-encrypt-files-with-powershell
Even just use EFS, but each of those have several limitations.
https://technet.microsoft.com/en-us/library/bb457116.aspx
Then there are password encrypted zip files. But.....
None of the above stop cut/copy/paste/print and there is no way to make them.
Here is the simple truth to data security which I deliver at all my public speaking engagements and customer deployment engagements.
Nothing can defeat and ocular attack. Meaning...
'If I can see your data, I can take your data.'
It may take me longer than being able to just bulk exfiltrate you data (copy to a USB, CD, DVD, native print, etc), but I can just take a picture, photo copy it, screen grab it from another device, manually write it down.
Either method allows me to walk away with it and give it to whomever.
You can only mitigate / slow down / prevent bulk exfiltration using DLP/RMS protection solutions.
Why are you putting this manually on their systems, vs hosting it in the cloud where they can access it. If you do this in MS Azure, you can leverage Azure Information Protection.
RMS for individuals and Azure Information Protection
RMS for individuals is a free self-service subscription for users in
an organization who need to open files that have been protected by the
Azure Rights Management service from Azure Information Protection. If
these users cannot be authenticated by Azure Active Directory and
their organization does not have Active Directory Rights Management
(AD RMS), this free sign-up service can create an account in Azure
Active Directory for a user. As a result, these users can now
authenticate by using their company email address and then read the
protected files on computers or mobile devices.
https://learn.microsoft.com/en-us/information-protection/understand-explore/rms-for-individuals
Why are you not heavily watermarking your data?
Putting passwords on files and folders do not prevent that ocular attack.
Neither does DLP/RMS. You can apply cut/copy/paste/print policies, remove access after a certain date, restrict access as per the feature set using policies.
Yet, again, this is just prevention against the bulk dumping / sharing of your data. Not the fine grained, patient, write it down or capture from a remote camera approach. Even if you block cut / copy / paste from the host, I can bring that host up is a screen sharing - think remote desktop, and screen shoot in the RDP session. Meaning, using the host tools that I use to connect to an RDP destination. Heck I create a webcast and share it with a group, meaning, I open it on my system and let people view it with me.
No DLP solution is 100%. Anyone telling you this is lying.
As one that has been doing Info/CyberSec for almost 2 decades, evaluated, deployed and used several DLP solutions, what I state here is from experience. DLP is important, and business must look to it as another mitigation in their risk strategies, but must do so with real vision and reality.
No matter who it is from, no technology can prevent this ocular avenue. If you don't want your data leaving your control, then don't share it. Yet, since you are in the education business, that is not an option.
I'll say it again, and again...
'If I can see your data, I can take your data.'
I have developed a .NET Windows Service (in VS2010) that needs to:
Access shared folders (read/write) on machines on the local network
Write to HKLM/SOFTWARE part of the registry
Write files and create folders in all parts of the local file system (ex. in root of C:)
Download files from the web (using http)
My service must do well with all Windows (PC) operating systems, starting from Windows XP SP3 and onwards.
Problem: Which service account should I choose for my service?
Normally, I would use either “LocalService” or “NetworkService”, but none of those grants all needed privileges by themselves.
Should I use the “LocalSystem” account then? Or, should I create a complete separate account for my service's use only (this should then be done automatically during installation)?
For now I use the “NetworkService” account and just adds it to the adimistrators group during installation, which works fine. But I think this approach ruins the whole idea about limited service accounts and thus poses a security risk - don’t you agree?
You should not use LOCALSYSTEM. This has far too much power and all best practice tells you not to use it.
In my view you should be creating a local user with appropriate rights as part of your installation. This is a fairly common practice for server/database products.
Sounds like you need to separate out your requirements.
You mention needing access to shares on other computers, but then you also mention that the machines this service will be installed on won't necessarily be part of the domain.
Have the service execute under a user account that grants you the appropriate LOCAL permissions. Then have some type of alternative user account with access to the appropriate shares that your service knows about and impersonates when needed.
Now, with regard to writing and creating files in the ROOT, that's going to be interesting. Your service will need full administrative permissions in order to do this on a Windows 7 box if UAC is turned on. Which, it would probably be safe to assume is on machines you don't directly control. Either eliminate this requirement or you'll have to live with the idea that your service is a security risk.
I have a python application designed to run as a service on Linux, and I've been asked to install it on a Windows XP box in an office where there are no Linux machines (for me, this makes it a bizarre and confusing place as I have virtually no experience developing for Windows).
On Linux the application has its own user, and the application and database credential file reside in an encrypted folder accessible only by that user. (I'd like to state that I am not a cryptologist, and that if there are already glaring security errors in this set up I'm very happy to have them pointed out to me!)
How can I achieve an equivalent level of security by similar or different means on a Windows XP machine? That is to say, how can I prevent those who have access to the computer or the disk altering the program or reading the credentials?
A little background: the host windows box is a workstation used every day by users with non-administrative privileges. The secure assets are personal data roughly as sensitive as, for example, a school report. The application is intended to be used by about 10 people who authenticate to the application with individual passwords (stored salted and hashed in the database).
There is a very similar question that received the answer:
on Windows you would store the credentials in the registry in a location protected by an ACL
However, it doesn't touch on the aspect of protecting the program files, and further it seems to assume a higher level of Windows experience than I currently enjoy :) I have no idea how to protect registry items with an ACL, nor how I would then be able to access the protected keys from my program. Simple instructions for a developer in an unfamiliar environment would be greatly appreciated!
Your question is unclear about what your application does and what your security requirements are. I'm going to make some assumptions, and provide an answer based on them. If these assumptions are incorrect, please clarify in a comment and I'll update.
I'm assuming you have an application that:
stores sensitive data in a database stored in a DBMS installed on the workstation
is installed on a shared workstation
each user has their own login (non-admin)
allows different users to log on and interract with their data
user runs applicaiton which connects to a service
service connects with database, delivers data to users
service runs under its own user account
If this is correct, then you shouldn't have much issue.
The service can run under any account, but it would be easy enough to have it run under one of the standards (Local Machine or Network Service). Configure the database so that only this account can access it. In Sql Server, I'd only grant that user account (and admins on the box) login and access rights to the database.
This is the only security you need, if the users aren't admins. Now, when the frontend connects to the service, the user can provide the username/password and the service can authenticate against salted and hashed passwords stored in the database. All this is secure as long as 1) each user has their own login 2) communications are secure (using named pipes or SSL) and 3) no virii or keyloggers are running under an admin's credentials.
You can configure your service as to what account it runs under by running services.msc (or right-clicking on MyComputer and selecting Manage or clicking on Services under the Admin tools menu in Control Panel or probably in a number of different ways).
Bring up the list of services, right click on your app and hit Properties. From there, make it look like this:
Let me state first: I know that any user that wants to run a program (or even log in), has to have access to (probably at least) the Windows system directories and the shared libraries in %ProgramFiles%, but I'd like to be able to access Skype, for example, by running it with an unprivileged user and make sure that it can't access any unnecessary files.
I fear that the only way to do this would be to identify all of the gazillion directories where I store files that I don't want this user to access and then create a new user group that can access these directories, or run Skype and Azureus in a VM.
Is there a better way?
Normally, accounts are members of the Users group at least, which does have access to many things. You could make the account a member of no groups, or the Guests group which is very restrictive.
The real issue is that the program's token (an internal security object that keeps track of what security identities a running process has) will contain the Everyone and Authenticated Users groups, which also have read access to lots of stuff. There is no way to create an account without those groups. You could remove the access that Everyone and Authenticated Users groups have to most everything, but it would be a lot of work to track all those down.
I would say that creating a standard user or guest access account for untrusted programs would be plenty secure enough. To support self-updates and to keep related files in the same place, I suggest you install those programs directly in the profile of the user account they will be running as, e.g. C:\Documents and Settings\skype\Program Files\Skype
If you want to get really fancy, you can use a restricted token to either make the Everyone, Authenticated Users, etc. groups deny only (so they can't grant any access) or create a Restricted SID list. This will be difficult to implement because there are global objects that programs will expect to access that the Everyone group has access to, which is normally a safe choice.
See CreateRestrictedToken Function.
There is also an open-source command line program I created a program for creating restricted tokens and job objects on the fly for that purpose: UlimitNT
Maybe sudown is a solution. It's a sudo-similar (as known from Linux) approach to running as unprivileged user, but having the possibility to promote to an administrative account (with password) when needed.
I suppose you could lock down the machine so the user can solely log on, not even start skype with his rights, but start skype by "run as" with sudown.
Besides using a VM you could look into using a Sandbox. Look at Sandboxie fox an example.
simply use acl apis (samples in msdn)