I want to secure some resources (like files, videos, etc.), by limiting access, by assigning different permissions & authorities to different users or group. Can I achieve this with LDAP?
If yes, how?
Also, if you can provide some good read on this topic, it would be really helpful.
Your response will be much appreciated
Tried searching, but not found solution in term of resources.
Related
I would like to store user profile information. After researching a bit online, I am confused between the following options:
Use a LDAP server (example: Open DJ) - I can write Java clients which can interact with the LDAP server using LDAP APIs.
Store user profile in a database as a JSON document (like in Elastic DB) - The No SQL databases can then index the documents to improve lookup time.
What are the factors that I should keep in mind before selecting one of the approaches?
For a start, if you are storing passwords, then using LDAP is a no brainer IMO. See http://smart421.com/smart-identity-and-fraud/why-bother-with-an-ldap-anyway/ .
Otherwise I would recommend you do a PoC with each solutions (do not forget to add indexes for OpenDJ and you may also use Rest2LDAP) see how they fill your needs. Both products are open source so its easy to get started.
If your user population is a known group that may already have accounts in an existing LDAP repository, or where user account information needs to be shared between systems, then it makes sense to use and add on to the existing LDAP repository.
If you are starting out from scratch and have mainly external, unknown users who have no other interaction with your infrastructure but this one application, then LDAP is not a good choice imo because of the overhead that you are getting for creating and managing the server. Then a lightweight JSON approach seems better suited (even thought the L in LDAP stands for "lightweight").
The number of expected users is less of a consideration - you need to thread carefully with very large populations in either scenario.
See this questions as well for additional insights Reasons to store users' data in LDAP instead of RDBMS
I am using openLDAP storing users. where should I keep user session details as it we need to track few user details for a session. What is Ideal place to store user sessions?
Thank you...
Despite the fact that the question is off-topic I'd use redis as it is fast and simple. You'd only need a key-value store for keeping session information and not a fully grown directory server. LDAP might be fast in getting Information out of it, but you would need to put the information in first and update those informations on a regular basis which isn't what LDAP has been designed for.
Lets say i have a website mysite.com that will store some sensitive personal data (bank related)
On this website i have an oracle database with a USERS tables that will store the logins and passwords of users from mysite.com
I have a few questions :
How should i store passwords,encryption of course, but which ?
What should be the process for registration ? send an email to confirm is really necessary ?
Any good advices on login processes in general ?
For information, i m using Oracle APEX
You're storing bank related sensitive personal data. Don't hack your own solution. Use an existing, proven solution. Most likely you will also be running into all kinds of security and privacy laws, regulations and liabilities when dealing with such data. Find someone who knows these regulations and who can help you and advise you.
Don't try to do this yourself. "Anyone can build a security system they they themselves cannot break." - I think that's a Bruce Schneider quote. Heed it.
Edit to react on comment:
Even when dealing with private finance software you're probably dealing with bank account numbers, social security numbers, etcetera. So you are probably still running into various kinds of regulations.
Systems like OpenID and Oracle SSO only cover authentication. Regulations also dictate minimum security measures on how you should store data in your database, how you should treat backups, how you should deal with people (e.g. developers) accessing the database, etcetera, etcetera. If you don't follow these and something goes wrong, you're liable.
I really urge you to seek help from someone knowledgeable in the field. Explain them what you want to do, what you want to store, etcetera. They can tell you what (if any) regulations apply. Only then can you start looking at how you are going to implement this and what off-the-shelf components you can use.
Under no circumstance should a password be encrypted. The use of encryption implies that there is a decryption function and that would be a violation of CWE-257. Passwords must always be hashed, and SHA-256 is an excellent choice. The password should be salted with a cryptographic nonce. Authentication systems are highly simplistic when taking into consideration the other security systems you rely on.
You must be VERY CAREFUL to make sure that your system is free of SQL Injection. I recommend obtaining a copy of Acunetix($) NTO Spider ($$$) or wapiti(open source). In any case parameterized quires is the way to go.
Take a look at the answers to this question.
Passwords should be stored as a salted hash. Use a unique salt for each. For hashing there are better alternatives but SHA1 is alright for many purposes (its available via DBMS_CRYPTO). Even better go for SHA256 (using http://jakub.wartak.pl/blog/?p=124).
User registration confirmation really depends on the site. If you want to get users in quickly then you could allow them in after registration for a limited time until they click the activation link. All the activation really gets you is a real email address to associate with the user. Also consider captcha to prevent automated/scripted sign-up.
Login should enforce temporary lockout after some invalid attempts (and alert admins when successive lockouts are hit). Enforce a password complexity too.
OWASP has very good general advice on secure web app design.
Wikipedia has some information on Oracle Apex Security. Another comment suggested a web testing tool such as Acunetix or NTO Spider (I would suggest Burp instead), there is also a tool for testing the security of Apex applications through analysis of the source (ApexSec) - (disclosure, I work for this company).
You could also consider a third-party view on you application, be that penetration testing or code review. A Web Application Firewalls can provide some value depending on your context.
We're building an application designed to run on Windows-based servers. One of the considerations we're looking into at the moment is how to control access to the application's GUI, which allows configuration and controls the "back end" services.
In order to secure the application properly, there are several objects which will need ACLs to be applied - files, directories, Registry keys, named pipes, services etc. We need to provide administrators with some way to configure those ACLs in order to limit access to authorized users only.
One approach we have considered is to create a tool which can modify the ACLs on all those objects simultaneously, but that would be a fair chunk of work and could be fragile.
The other possible approach we're looking at is to create a custom group (e.g. "My App Users") so we can give that group the appropriate rights to each object. This means that administrators will be able to add/remove authorized users by using familiar Windows group membership tools.
So: is creating groups at install time an acceptable thing to do, or is it likely to upset administrators? I'm more familiar with the UNIX world, to be honest, where server-based apps are more or less expected to create groups, but I'm uncertain of the etiquette in the Windows ecosystem.
Also: is there a better solution to this that I've missed?
Thanks in advance!
The question is twofold - one technical, and one political. Technically a local group is fine, you can add AD or domain users into a local group and everyone's happy. In terms of whether an app should be messing with a server's security 'stance', the only reasonable answer is to pop up some kind of request telling the user what you are going to do and asking permission (make sure you also document the decision in some kind of log or entry). This also addresses everybody's legal a$$ eg if they click "no, leave my app unsecured" and get hacked).
Taking a UNIX approach, you could tell the user what you need, suggest a local group (and give the user the chance to pick another local or domain/AD group). Take a look at how (eg) Oracle installs on UNIX do it.
Since this is a server app and you might have to support silent/unattended install, make sure that the behavior can be specified in the install script and very, very sure that the behavior of the script is documented so that no one installs the program without realizing the change in security policy that the installer implements.
I think it's perfectly fine to create a local group for this purpose.
Furthermore I have not been able to come up with a better solution after giving it some thought.
Depending on the size of the implementation, groups could be the way to go.
But please keep in mind that the relevant ACLs on directories and the registry ought to be set. I do agree that setting them once to the group and then let access control be maintained by group memberships.
In regards to klausbyskov's answer, I think a local group could be fine, but consider using LDAP instead. From a security perspective you would detach the authentification process and let the Directory handle it; using kerberos.
If I built an application that accessed some of the data from say Gmail, Twitter and Facebook, and I want the user to be able to only have to enter their authentication info once, and it's reset after some days or weeks, what is the best way to do this, dynamically, in Ruby?
I see a lot of people just having a config file of their clients'/users' credentials like so:
gmail_account:
username: myClient
password: myClientsPassword
This seems a) like it's very insecure, and b) it wouldn't work if I wanted to store this kind of information for thousands of users. What is the recommended way to do this?
I would like to be able to build an interface on top of these services, so having to enter credentials every time the user made a transaction isn't feasible.
If you're comforatable with the potential liability when a hacker gets into your database / filesystem, then go for it. And in all fairness, you should also disclose to your users that their passwords will be stored on your system, and let them decide if they want to give your program that level of trust.
But why do this in the first place? Facebook Connect and Twitter & Google using OAuth there's no need for you to store user passwords at all. At some point a user's cookies will expire (or they'll try to access your site from another computer) and they'll have to re-authenticate. You can't prevent re-authentication - instead, you should make it as easy for the end user to handle as possible.
Such services are providing OpenAuth authorization. You are strongly recommended to have a look at it.
Security
I assume your application needs to know the password in plaintext. Then there is no way around storing it in some kind of plain way.
Store in some kind of encoded way eg. Base64, this protects you from knowing password when looking through the database with your eyes, but it does not protect you from anything else.
Ensure that the files are not readable from any other user
Encrypt your harddrive, so nobody can get the passwords from stealing your harddrive. Your computer will require inputung you the password during booting.
Storing
There is nothing wrong with storing much data in your filesystem. For better performance you can do the following
One file for each user, so the filesystem and not ruby needs to search for the data
Make a lot of subdirectorys. Some filessystems performance suffer's if you put to many files into one directory. eg. put the file 'abcd' into 'a/b/c/d'
You could use a database instead of the filesystem
This is the way it works for instance for fetcmailrc which has to be chmod to 600 (readeable and writable only by his owner). And yes, it contains the plain password.
I would strongly suggest you to use OAuth, but if you have to store the passwords (please be absolutely sure that you need to do it) you could use the OpenSSL library to encrypt the passwords. The OpenSSL library is quite poorly documented in Ruby, but as far as I know they are quite similar to the C OpenSSL library. Since I think you should use OAuth, and not storing the passwords I'll let you find the documentation yourself.
However, for the OAuth approach, you want to take a look at the OAuth gem. Google, Twitter (which I recommend you to use the excellent twitter gem for) and facebook (which has two seemingly good alternatives: RFacebook and facebooker)