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.
Related
When trying deploy my Release to a Server using a local Admin Account at the Server i get the Message:
7-05-09T08:12:50.6866361Z 2017/05/09 10:12:50 ERROR 5 (0x00000005) Getting File System Type of Destination \\server\C$\temp\
2017-05-09T08:12:50.6866361Z Access is denied.
during the robocopy to the remote server.
When trying to use my domain Account (also Administrator) it works without any problems.
What am i missing?
Make sure that the UNC path \\server\C$\temp\ could be achieved by the local account you used as build service account.
I suggest that you use domain user to access the domain resources. Or you could share that folder \\server\C$\temp\ to Everyone and give the Read and Write permission.
If you insist to use a local account, as a workaround:
local accounts on each member server where the shared folders are
stored will have to be created to directly map to the same
username/password combinations the users are using on each local
machine. For example, on client 1, local user named A, password xxxx,
on the server which stores the shares, you need to create a local user
named A with the same password xxxx.
I'm working with hyperledger fabric in the stable version.
In the CA, the users with their password are stored in clear-text on the membersrvc.yaml file in $GOPATH/src/github.com/hyperledger/fabric/membersrvc.
Is it normal ? Is there an other way to create the users when I launch the CA without having the crendentials in clear text ?
The userid/password combination present in the membersrvc.yaml can be used only once. Think about it as an OTP. If you want to reuse it again, you have to bring down the membership service instance and you have to clean up the user data store in the /var/hyperledger/production/db directory (And as of now, as per my information, there are no plans to include a logout API which might have enabled the usage of the credentials again without clean up).
If you want to add a new user to the Fabric, then this can be done programatically with the Member.register method - while using Node.js SDK. But the user would exist only during the life cycle of the Fabric ( ie, till a clean up is performed).
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 have a windows desktop app (written in Delphi) that allows users to store and retrieve files.
The application stores these files in a single network shared folder (Active Directory).
The various users of the app do not all have permission to see all of the files, these permissions are controlled by the app.
Currently we have to allow every user of the app access to the shared folder, so a malicious user could find the directory and gain access to all of the files.
Is there a way that the app can act as a specific user such that only the "app as a user" and not each individual needs permission to the shared folder?
You need to either:
1) run the app as the desired user.
2) have your code programmably impersonate the desired user, via LogonUser() and ImpersonateLoggedOnUser(), or other similar functions, before then accessing the shared folder. Don't forget to stop impersonating when you are finished using the folder.
Not directly, no. The app has exactly the same rights as its user has. That's part of the OS's security model. If I had to deal with something like this, I'd do it this way:
Create a second program that runs as a Service, and set it to run under a user account that has access to the shared folder. It should implement some sort of validation logic, and listen for incoming messages. (What exact method it uses for this is up to you, but you're essentially creating a server.)
Your desktop app runs under the limited user accounts. To request a file, it sends a message to the server, in which it identifies the user and the request it's making.
The server checks the request, and if it's valid, retrieves the file and passes it back to the user app. If not, it should return some sort of error message.
Not with standard file sharing -- the application is always going to running in the security context of the logged in user.
There's 2 obvious solutions I can see:
Work with the AD security and user accounts you already have in place to modify the rights to the files in the shared folder. This only works if the security in your application can be mapped to AD security objects already. If you need to allow for impersonation (e.g. An administrator "logging into" the app as himself or herself from another user session), then you're going to need to get very comfortable with the various Windows Security APIs.
Write a server-side component that will handle your application's authentication mechanism and provide file listings and content to the client.
It's possible that #2 could be implemented with something like WebDAV, FTP/SFTP/FTPS, or some other "already done" file transfer protocol that you can piggy back off of to save you some work.
I am creating a Twitter client for Mac OS X and I have a Consumer secret. It's to my understanding I should not share this secret key. The problem is that when I put it as a string literal into my application and use it, like this:
#define QQTwitterConsumerSecret #"MYSECRETYOUMAYNOTKNOW"
[[QQTwitterEngine alloc] initWithConsumerKey:QQTwitterConsumerKey consumerSecret:QQTwitterConsumerSecret];
It is in the data section of my application's binary. Hackers can read this, disassemble the application, etcetera.
Is there any safe way of storing the Consumer secret? Should I encrypt it?
There is no real perfect solution. No matter what you do, someone dedicated to it will be able to steal it.
Even Twitter for iPhone/iPad/Android/mac/etc. has a secret key in there, they've likely just obscured it somehow.
For example, you could break it up into different files or strings, etc.
Note: Using a hex editor you can read ascii strings in a binary, which is the easiest way. By breaking it up into different pieces or using function calls to create the secret key usually works to make that process more difficult.
You could just base64-encode it to obfuscate it. Or, better idea, generate the key instead of just storing it - write something like this:
char key[100];
++key[0]; ... ; ++key[0]; // increment as many times as necessary to get the ascii code of the first character
// ... and so on, you get the idea.
However, a really good hacker will find it no matter what; the only way to really protect it from others' eyes is using a secure hash function, but then you won't be able to retrieve it, too :)
You should not use a secret api key in an application that does not run solely on your server.
Even if it's perfectly hidden.. you can always snoop on the data going through the wire. And since it's your device you could even tamper with SSL (man in the middle with a certificate created by a custom CA which was added to the device's trusted CA list). Or you could hook into the SSL library to intercept the data before actually being encrypted.
A really late answer...
If you setup your own server, you can use it for helping you desktop app getting authorized by users on twitter without sharing (i.e.: embedding) your secret key.
You can use this approach:
When a user installs you desktop app she must register it with twitter and with your server
*)
*) The app asks the server to generate the token request URL
*) The server sends the generated URL to the app
*) The app directs the user to the authorize URL
*) The user authorizes your app on twitter and pastes the generated PIN into it
*) Using the PIN you app grabs the token
*) All further communication uses the token and does not involve your server
Note: the app logs to your server using the user credentials (e.g.: id and password) for your server.