I have been attempting to access different OID's with no luck and significant research has lead me to believe that snmp is just configured to protect these parts of the system and I simply don't have access. How do I change the configuration to allow access to all OID's?
Or, how do I create a user who requires no authentication and no encryption (no priv)?
Related
Attention: Please read this topic carefully: This question is not seeking recommendations for books, tools, software libraries, and more. Instead, I am seeking for a method behind existing crypto in applications. A similar previous question got locked - IMHO due to a misunderstanding.
I am looking for the method (and maybe an implementation hint) how others obviously safe password on user drives in a safe way. For example on Windows: You can easily store the passwords of RemoteDesktop sessions w/o the need of entering a password when re-opening the session (even after re-starting your PC). Similar is the case for SMB connections or connections to SharePoint drives. My assumption is therefore, that there must be a safe way to safe passwords. This is what I want to understand. There are (closed source) tools around that store the password in some kind of hash in a file - which only works on that particular computer. This is what I am looking for but hopefully without the need to use excessive crypto libraries.
The background is that I am developing a native cross-platform app (esp. not a web-app but C++) that requires the input of a user name and password to connect to a proxy server. For convenience I want to store this sensitive information encrypted in the settings file of the app, which has INI-File format. Therefore, the file itself shall not be encrypted.
Does someone know an easy algorithm or method to do so?
I did find and tried algorithms based on SHA hashes and so one but they all either required a master password (which doesn't help because the point is exactly not to enter a password) or they literally used tons of crypto-libraries and non-cross-platform APIs which makes it hard to come to a cross-platform implementation.
All of these capabilities ultimately depend on a randomly generated master password that can only be read by a specific logged in user.
The safe way to store such a password is to encrypt it with a password that is generated from a hash of the user's login credentials.
If the user has multiple ways to log in, then a different copy of the master password must be stored for each login method, encrypted with a password generated from a hash of whatever credentials the user must supply for that particular login method. This generally requires OS support.
Often, implementations don't explicitly bother with this, instead relying on file system security to ensure that only the desired user can read the master password. In that case, though, you need to use disk encryption if you want to prevent the password from being accessed by super users or other means of bypassing file system security.
The disk encryption, though, will have its own master password encrypted with a login credential hash.
In RethinkDB, there does not seem to be built-in support for user roles/access permissions.
This seems to be a common feature in most established databases, including MongoDB. We are worried that this gives processes that have access to the database too much access and us as developers little control over who can access what, leading to potential security issues.
I'm wondering: How big of an issue is this? Is there an alternative way to replicate this functionality without rethinDB supporting it out of the box?
EDIT:
As of RethinkDB 2.3 which was just released, you can now add users and ACLs!
2.3 Release Blog Post
Users documentation
Original Answer
access control (sometimes ACL) for RethinkDB is on the road map but in the mean time I recommend to either setup multiple instances divided by user permissions of RethinkDB along with an auth key:
https://rethinkdb.com/docs/security/#securing-the-driver-port
RethinkDB allows you to set an authentication key by modifying the
cluster_config system table. Once you set an authentication key,
client drivers will be required to pass the key to the server in order
to connect.
Hope that helps!
Are there any examples of using encryption to encrypt the disk-cache used by OkHttp's HttpResponseCache? Naively, I don't think this is a very hard thing to do, but I'd appreciate any advice or experience to avoid security-pitfalls.
Without too many specifics, here's what I'm trying to achieve: a server that accept user's api-keys (typically 40-character random string) for established service X, and makes many API calls on the users behalf. The server won't persist user's api-keys, but a likely use case is that users will periodically call the server, supplying the api-key each time. Established service X uses reasonable rate-limiting, but supports conditional (ETag, If-Modified-Since) requests, so server-side caching by my server makes sense. The information is private though, and the server will be hosted on Heroku or the like, so I'd like to encrypt the files cached by HttpResponseCache so that if the machine is compromised, they don't yield any information.
My plan would be to create a wrapper around HttpResponseCache that accepts a secret key - which would actually be a hash of half of the api-key string. This would be used to AES-encrypt the cached contents and keys used by HttpResponseCache. Does that sound reasonable?
Very difficult to do with the existing cache code. It's a journaled on-disk datastructure that is not designed to support privacy, and privacy is not a feature you can add on top.
One option is to mount an encrypted disk image and put the cache in there. Similar to Mac OS X's FileVault for example. If you can figure out how to do that, you're golden.
Your other option is to implement your own cache, using the existing cache as a guide. Fair warning: the OkResponseCache is subject to change in the next release!
follow up to: Windows Filesystem Minifilter Drivers: can I monitor and prevent FS operations using them?
I'm looking for a method to filter access to certain file system resources.
This includes removable media and non-ntfs file systems - so standard ACL won't work.
from what I read, a files system driver filter might be helpful - but I didn't find a way to get the user id of the initiating user.
Is this possible?
other recommendations \ references to existing tools are also welcome.
I am not sure what does "user id" mean. But this might be useful:
When handling IRP_MJ_CREATE look at IrpSp->Parameters.Create.SecurityContext->AccessState.
ACCESS_STATE contains SecurityDescriptor and SubjectSecurityContext.
From SubjectSecurityContext you can retrieve PACCESS_TOKEN if you need it (call SeLockSubjectContext and SeQuerySubjectContextToken).
Have a nice day!
In most cases obtaining security information (token) of the user that initiated the call is possible, at least for operations such as file open and directory enumeration (and these are main points of filtering when you plan to prevent access of the user to the resource). And then you can cancel or modify request as you need. The only limitation I can think of is when the network redirector accesses the disk on behalf of the remote user impersonated as local system account. But these are border cases that you would need to investigate yourself in your particular task.
Is it possible to store passwords on the local system (Windows XP) that can only be accessed by the application itself?
My instinctive answer would be "no". Even if some kind of hashing or encyption is used I would think that as long as the source code is available then the determined seeker could always use this to retrieve the password.
I'm working on a personal open source hobby project in which I would like to give users the option of storing passwords on disk so that they don't need to type them every time they use the software. One example of a password that could be stored would be the one used to authenticate on their network's proxy server.
There are a few related questions here on Stack Overflow and the most appropriate solution sounds like using an operating system service like DPAPI.
Is the basic premise correct that as long as the password is retrievable by the software without any user input, and the source code is open source, that the password will always be retrievable by a (suitably technically and willfully inclined) passer-by?
You could read about the Pidgin developers' take on it here:Plain Text Passwords.
Using the DPAPI in UserData mode will only allow your account on your machine to access the encrypted data.
It generates a master key based off of your login credentials and uses that for the encryption.
If the password is retrievable by the software without any user input, then the password will always be retrievable by a (suitably technically and willfully inclined) passer-by. Open or closed source only affects how much effort is involved.
Absolutely, you can write a program to store passwords securely.
Using AES, you could have your program generate an AES Key, and have that key stored in an operating system protected area. In WinXP, this is the registry, encrypted with DPAPI. Thus the only way to access the key is to have physical access to the machine.
You need to ensure that when you generate your AES key that you do so in a cryptographically secure manner. Just using RAND won't work, nor will generating a random character string.
Open Source has very little to do with security (in my opinion). Given the level of sophistication in tools for reverse engineering source code, even if you had a closed source solution, people determined to snoop at your code could do so.
Your effort is better spent ensuring that you follow best practice guidelines while using the chosen encryption scheme. I would argue that having your code openly looked at by a larger community would actually make your code more secure; vulnerabilities and threats would likely be identified sooner with a larger audience looking through your code.