I'm working on a thesis with the goal of a blockchain based approach to continuous integration. Reading this paper I noticed the strongly diverging understandings and implementations of continuous integration particularly looking at the points 'Definition of build failure and success' and 'Fault handling'. My idea is to use blockchain and smart contracts as a voting mechanism between a pull request by a developer and the build results of the CI servers. The image below is what I thought of.
When a developer sends a pull request a transaction is proposed to the blockchain network which sends the build candidate to the CI servers. The CI servers post their outcome in the form of votes back to the blockchain network and depending on the consensuns mechanism (majority or absolute vote) the build is accepted and the branches are merged.
However I'm new to the world of blockchain and it's unclear to me how to apply consensus mechanisms like PoW or PoS and smart contracts. Maybe some of you could help me answer a few questions or give advice on how to design it.
How do I approach PoW or PoS here? What exactly is being mined here? Does a transaction require a cost? Do I even need those things or can I simply use blockchain as a data structure?
The obvious question with blockchain is why I would even use it in this case. From my own DevOps experience I see through all projects a lack of standards and rules and problems with role-based access control. This includes improved transparency of the system mechanics and traceability throughout the project.
This being a bachelor thesis I'm not trying to revolutionize computer science, my goal is learn more about CI and if blockchain can do any good. The topic and design of the system above is approved by my supervisor.
Apart from cryptocurrencies, the main cases of using blockchain platforms are:
creation of a trusted operating environment among participants who do not trust each other;
building a system of interaction without a point of failure - technical or organizational, when the elimination or malicious intent of any node does not lead to the inoperability of the system as a whole;
construction of a cheap distributed database.
In your case, using blockchain in the sense of a decentralized platform is imprecise and most likely ineffective. One of the main problems in building a blockchain network is determining who will be the owner of the node and why (what are his incentives for this).
In your case, it is difficult to think of rational reasons why each developer (or at least a group) would want to own the nodes instead of using some centralized service. Moreover, you have a guaranteed "centralization point" - a CI server. It might be worth considering an infrastructure with multiple independent CI servers. But even here I still do not see the benefits of using a decentralized solution.
Technically, the use of a blockchain platform for voting in your case does not present any apparent difficulty when implementing almost any voting algorithm - you can use a private Ethereum, Quorum or Hyper Ledger Fabric.
Regarding your question (1), PoW or PoS are technical mechanisms for determining the blocks of the main chain of public blockchain platforms. Your smart-contracts will work on top of this protocol and, most likely, implement consensus algorithms from the BFT group (PBFT, IBFT, and so on).
Our data protection officer, in relation to the judgment c-311/18 (https://edpb.europa.eu/news/news/2020/statement-court-justice-european-union-judgment-case-c-31118-data-protection_pl), questioned the possibility of storing personal data on Webfaction's machines:( Unfortunately their DATA PROCESSING ADDENDUM in point 9 - Transfers of Personal Data (https://www.webfaction.com/local_media/WebFactionDPA.pdf) mentions the possibility of transferring data to the US under the EU-US Privacy Shield Frameworks, which was challenged by the aforementioned judgment.
In the opinion of our DPO, it is not possible to use the webfaction services until this provision is changed. Do any of you also have this problem? Maybe a different legal opinion?
Not a good answer, but I'll give it anyway.
Before being acquired, I believe that Webfaction was based in the UK, and you could request servers in Europe. I don't know whether this is still true or relevant.
You might want to consider Opalstack as an alternative. It's a lot of what Webfaction used to be pre-aquisition, and I believe has servers in Europe. I've been exploring switching to them, and have been happy so far. However, I believe that their ownership is technically in the United States.
I am not a lawyer, an expert, or anyone who can offer an opinion on this. I'm just offering some additional information and options for you to consider.
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.
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.