I've worked at companies where an admin role is able to select and view another user's private data (view the system as if through another user's eyes). In today's day and age, is this good, ethical practice?
Generally yes. An admin is typically representing the data controller directly (and may even be employed by them), and access to their data is often both useful and necessary as part of the service they are providing. Data processors (third parties acting on behalf of the data controller) in that role are subject to a data processing agreement that will usually include confidentiality requirements – this is something I do quite often.
That said, there are scenarios where you may be handling "special category" data (to use GDPR terminology), such as medical records, where you may need to be stricter about access and processing, and you might want to make use of security measures such as encryption of data at rest - admins in that situation can control exactly what the database server does, but may not be able to see what the data contains (for example using the encryption mechanisms provided by CipherSweet).
In special category situations, GDPR requires that you conduct a data protection impact assessment (DPIA) and/or a privacy impact assessment (PIA) before implementing solutions, so that you you are able to justify your decisions should an information commissioner ask for it. These sound onerous, but they are actually an interesting exercise, helping you introspect about your internal practices more objectively. Take a look at the excellent open-source PIA tool published by the French information commissioner, CNIL, to help you build these.
So in short, it's generally OK, but there may be cases where you don't want to allow it, or only allow it when using additional security measures.
Related
I have a requirement to persist some data in a table (single table). The data is coming from UI. Do i need to write just the system API and persist the data OR i need to write process and system API both? I don't see a use of process API in this case. Please suggest. Is it always necessary to access system API through process API or system API can be invoked without process API as well.
I would recommend a fine-grained approach to this. We should be following it through the experience layer even though we do not have must customization to the data.
In short, an experience layer API and directly calling System layer API (if there is no orchestration/data conversion/formatting needed)
Why we need a system API & experience API? A couple of points.
System API should be more attached to the underlying system. And if
in case, in the future, it changes then it should not impact any of
the clients.
Secondly, giving an upper layer gives us the feasibility to add
different SLAs, policies, logging and lots more, to different
clients. Even if you have a single client right now it's better to
architect for the future. Reusing is the key advantage of these APIs.
Please check Pattern 2 in this document
That is a question for the enterprise architect in your organisation. In this case, the process API would probably be a simple proxy for the system API, but that might not always be the case in future. Also, it is sometimes useful to follow a standard architectural pattern even if it creates some spurious complexity in the implementation. As always, there are design trade-offs and the answer will depend on factors that cannot be known by people outside of your organisation.
Are there any approaches or architecture design patterns to implement secure, clean role/permission based access control and UI conveniences without coupling them together?
The long story.
I have seen ambiguous use of roles and permissions in many web applications and I have often experienced how these ambiguities have caused misunderstandings and implementation difficulties.
Here is a simplified example.
Business requirements say that permission set for some specific role should deny access to some part of the system that displays a full list of addresses. But at the same time, users of this role will need to read the addresses for an autocomplete list on some other web page.
I have seen how reckless developers create a permission entry to disable access to addresses, and later they discover that users actually need to read the addresses from other parts of the system. Then they invent another specific permission for special cases where addresses can be read.
But for me it seems ambiguous and potentially risky situation. If user has no access to some specific data, then he/she shouldn't be able to access it at all. Period. Adding a special permission just for dropdown lists seems like a deliberate security hole. If user loads the list through an async request and the server is using the same controller action to return the list (and it should - to avoid code duplication), then how the server will know when it should not return the addresses, if they are sometimes forbidden?
This situation raises the question: "why shouldn't users of some specific role see the full list of addresses in the first place, if they have access to the list through some other means?" And the answer I often get from business analysts is something like "Well, the address list is not forbidden for data security reasons, but just because users of this particular role are not expected to do anything with the address list and it would be redundant item in their workspace".
So, now the problem seems clear to me: some permissions exist just for controlling the UI and not strictly for controlling access to some data. Such (ab)use of permissions feels wrong to me. Therefore the question which was given at the very beginning.
Good writing! It pretty much feels that you already have your answer.
IMO user profiling and user access are not the same thing. Access rights should be handled as low level as possible (eg. if or not a user has read-access to a specific SQL table) and profiling in this case should only apply at the UI level ("what the user actually wants or needs to see").
When we talk about an application that has some kind of access right control, there's almost always some kind of an "engine" behind the UI that actually holds all the data. The WORST thing ever you can do is implementing the security anywhere else than the engine itself. The data must never be accessible in any other way than through that engine's own access control or otherwise it's not access control - it's UI restriction.
But that's the perfect world :/ In reality, like in all areas of work, software development also has been driven torwards being more and more cost-effective, agile and responsive to the client. Not surprisingly, this guides people to do fast and cheap decisions... like "hell, let's just make another SQL procedure that pulls the data out as an admin" instead of "we need to re-evaluate user access rights, and/or possible redesign our tables to keep consistency with the access privileges". It's always a short-term (bad) solution WHEN it's done, but some solutions are definitely more NO-NOs than others.
As a guideline I'd say that if you're not 110% sure what you're doing, it's a biggest NO-NO there is.
TL;DR: If some data should be accessible even in one place, it's not restricted by access control. If it's unneccessary to show accessible data somewhere, use user/application profiling for filtering it.
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.
Update: this question is specifically about protecting (encipher / obfuscate) the content client side vs. doing it before transmission from the server. What are the pros / cons on going in an approach like itune's one - in which the files aren't ciphered / obfuscated before transmission.
As I added in my note in the original question, there are contracts in place that we need to comply to (as its the case for most services that implement drm). We push for drm free, and most content providers deals are on it, but that doesn't free us of obligations already in place.
I recently read some information regarding how itunes / fairplay approaches drm, and didn't expect to see the server actually serves the files without any protection.
The quote in this answer seems to capture the spirit of the issue.
The goal should simply be to "keep
honest people honest". If we go
further than this, only two things
happen:
We fight a battle we cannot win. Those who want to cheat will succeed.
We hurt the honest users of our product by making it more difficult to use.
I don't see any impact on the honest users in here, files would be tied to the user - regardless if this happens client or server side. This does gives another chance to those in 1.
An extra bit of info: client environment is adobe air, multiple content types involved (music, video, flash apps, images).
So, is it reasonable to do like itune's fairplay and protect the media client side.
Note: I think unbreakable DRM is an unsolvable problem and as most looking for an answer to this, the need for it relates to it already being in a contract with content providers ... in the likes of reasonable best effort.
I think you might be missing something here. Users hate, hate, hate, HATE DRM. That's why no media company ever gets any traction when they try to use it.
The kicker here is that the contract says "reasonable best effort", and I haven't the faintest idea of what that will mean in a court of law.
What you want to do is make your client happy with the DRM you put on. I don't know what your client thinks DRM is, can do, costs in resources, or if your client is actually aware that DRM can be really annoying. You would have to answer that. You can try to educate the client, but that could be seen as trying to explain away substandard work.
If the client is not happy, the next fallback position is to get paid without litigation, and for that to happen, the contract has to be reasonably clear. Unfortunately, "reasonable best effort" isn't clear, so you might wind up in court. You may be able to renegotiate parts of the contract in the client's favor, or you may not.
If all else fails, you hope to win the court case.
I am not a lawyer, and this is not legal advice. I do see this as more of a question of expectations and possible legal interpretation than a technical question. I don't think we can help you here. You should consult with a lawyer who specializes in this sort of thing, and I don't even know what speciality to recommend. If you're in the US, call your local Bar Association and ask for a referral.
I don't see any impact on the honest users in here, files would be tied to the user - regardless if this happens client or server side. This does gives another chance to those in 1.
Files being tied to the user requires some method of verifying that there is a user. What happens when your verification server goes down (or is discontinued, as Wal-Mart did)?
There is no level of DRM that doesn't affect at least some "honest users".
Data can be copied
As long as client hardware, standalone, can not distinguish between a "good" and a "bad" copy, you will end up limiting all general copies, and copy mechanisms. Most DRM companies deal with this fact by a telling me how much this technology sets me free. Almost as if people would start to believe when they hear the same thing often enough...
Code can't be protected on the client. Protecting code on the server is a largely solved problem. Protecting code on the client isn't. All current approaches come with stingy restrictions.
Impact works in subtle ways. At the very least, you have the additional cost of implementing client-side-DRM (and all follow-up cost, including the horde of "DMCA"-shouting lawyer gorillas) It is hard to prove that you will offset this cost with the increased revenue.
It's not just about code and crypto. Once you implement client-side DRM, you unleash a chain of events in Marketing, Public Relations and Legal. A long as they don't stop to alienate users, you don't need to bother.
To answer the question "is it reasonable", you have to be clear when you use the word "protect" what you're trying to protect against...
For example, are you trying to:
authorized users from using their downloaded content via your app under certain circumstances (e.g. rental period expiry, copied to a different computer, etc)?
authorized users from using their downloaded content via any app under certain circumstances (e.g. rental period expiry, copied to a different computer, etc)?
unauthorized users from using content received from authorized users via your app?
unauthorized users from using content received from authorized users via any app?
known users from accessing unpurchased/unauthorized content from the media library on your server via your app?
known users from accessing unpurchased/unauthorized content from the media library on your server via any app?
unknown users from accessing the media library on your server via your app?
unknown users from accessing the media library on your server via any app?
etc...
"Any app" in the above can include things like:
other player programs designed to interoperate/cooperate with your site (e.g. for flickr)
programs designed to convert content to other formats, possibly non-DRM formats
hostile programs designed to
From the article you linked, you can start to see some of the possible limitations of applying the DRM client-side...
The third, originally used in PyMusique, a Linux client for the iTunes Store, pretends to be iTunes. It requested songs from Apple's servers and then downloaded the purchased songs without locking them, as iTunes would.
The fourth, used in FairKeys, also pretends to be iTunes; it requests a user's keys from Apple's servers and then uses these keys to unlock existing purchased songs.
Neither of these approaches required breaking the DRM being applied, or even hacking any of the products involved; they could be done simply by passively observing the protocols involved, and then imitating them.
So the question becomes: are you trying to protect against these kinds of attack?
If yes, then client-applied DRM is not reasonable.
If no (for example, you're only concerned about people using your app, like Apple/iTunes does), then it might be.
(repeat this process for every situation you can think of. If the adig nswer is always either "client-applied DRM will protect me" or "I'm not trying to protect against this situation", then using client-applied DRM is resonable.)
Note that for the last four of my examples, while DRM would protect against those situations as a side-effect, it's not the best place to enforce those restrictions. Those kinds of restrictions are best applied on the server in the login/authorization process.
If the server serves the content without protection, it's because the encryption is per-client.
That being said, wireshark will foil your best-laid plans.
Encryption alone is usually just as good as sending a boolean telling you if you're allowed to use the content, since the bypass is usually just changing the input/output to one encryption API call...
You want to use heavy binary obfuscation on the client side if you want the protection to literally hold for more than 5 minutes. Using decryption on the client side, make sure the data cannot be replayed and that the only way to bypass the system is to reverse engineer the entire binary protection scheme. Properly done, this will stop all the kids.
On another note, if this is a product to be run on an operating system, don't use processor specific or operating system specific anomalies such as the Windows PEB/TEB/syscalls and processor bugs, those will only make the program even less portable than DRM already is.
Oh and to answer the question title: No. It's a waste of time and money, and will make your product not work on my hardened Linux system.
I have some doubt about aspnet_membership. My database team of my company dosen't let me use aspnet_membership. Because this feature use some stored procedure to install some thing that break the policy of my company. They said this feature could make some risk but I don't know what risk that I'll get if I used it.
Does anyone have any idea or reason about this issue?
Your "database team" is obviously paranoid. What sort of security risk do they anticipate if the aspnet_regsql.exe tool creates a database? I can understand that many Administrators feel uneasy using wizards because they want to know exactly what is going on behind the scenes. In this case, the command line tool allows you a high degree of customizability and should be preferred over the wizard mode.
Perhaps you and your database team should read up on the published implementation of the tool, rather than being obstinate about which you are ignorant. If you still find "Creating the Application Services Database for SQL Server" to be overkill, it is quite possible to create your own MembershipProviders and PersonalizationProviders and incorporate them with your own database structure.
I know this is an old question, but (as most good questions do) it made me think.
I can see the perspective of your database team in certain scenarios:
You are subject to compliance regulations that require complete separation of duties and thorough step-by-step documentation of every change made to an environment. This means that you can't just run any utility (no matter how well-documented or tested) on your own; you must hand it off to another team for approval, and that team must understand (in theory) every potential impact.
Perhaps there is a very granular object by object security policy in place, and your database team feels that auto-generated table structures would violate this.
Not a security breach, but depending on naming standards you have in place, the tables/procedures created by the tool may violate those conventions.
Perhaps you work in finance or healthcare and there is a specific set of security requirements that must be met. Either through ignorance or research, your database team believes that the membership database will not meet these requirements.
I've worked with many companies that have draconian security policies that often cause a great deal of extra time to be spent. Conversely, the consequences of not following those policies can have such dire consequences (multi-million dollar fines here in the US) that caution/paranoia usually wins out.
In summary: if the ASP.Net authentication/authorization scheme is a good fit, then invest the time in educating the database team on its internals so they can be comfortable with it. Listen to their objections; DBAs can be over-protective of their environments, but they often are responsible for key assets of a company.
As #Cerebrus pointed out, there are many different ways to use ASP.Net security. Try to leverage the parts that make sense. If your database team still doesn't "get it" (or raises valid objections) there are plenty of other ways to implement robust security in ASP.Net, they just require more effort.