A devops person setups a server, installs SSL cert and apps.
He/she would therefore have access to SSL cert and its private key.
How should he/she be off-boarded in a way so that SSL cert is not misused by him/her afterwards?
Should this be part of some contract or should the cert be renewed?
What is the best way such cases are handled in organizations?
would like to share my candid response in a manner that I deem fit. These are just my personal views.
A DevOps engineer is an integral part of any technology company, which is nurtured with trust and longevity. In terms of safety & security, they know all the weaknesses of the Development team (code) - and possible ways it can compromise the system. SSL is a very tiny piece in the big picture. One should be concerned for N number of other possible vulnerabilities in their system.
Every DevOps engineer chose to be one - because they love how cloud computing and the complexity of a secure network. They religiously ensure security & safety of the entire system 24X7 - in their best capacity. We value associations over petty money/disputes - and we lead an ethical life and not just act ethically on the work front. To add to this - I being one myself - I know how much effort, hard work, dedication and most importantly Time is required to gain client’s trust - I would never imagine throwing all my life work, just like that.
Coming back to a possible solution to your problem - pick up a team or an individual whom you TRUST - ask them to revisit the entire network and secure any vulnerabilities, if any. Changing the SSL would be recommended along with resetting all the passwords.
Related
We have code (in git) together with configuration/deployment/build scripts (fabfile.py, circle.yml, Dockerfile etc) which result in a pretty seamless automatic build/deploy process. The one part which is not seamless is where to store credentials of various kinds. These are things like ssh keys, code signing certificates, aws access keys, ssl certificates... Currently the process is to copy the needed keys/certs from a flash drive and then (eg) run fabric.
It seems like storing credentials like this in git (alongside code) is not the best place, but what is the best place? Is there a recommended best practice for where to store information like this for devops? Is there a reference that discusses different options with their pros and cons?
The problem of secrets management is still something that hasn't exactly been "solved" by the use of any tool.
You can use any of the various Secrets Management Tools (each offers different types of benefits / integrations).
I personally prefer Hashicorp Vault. Cyberark is another good one.
The way you use these tools in your solution however, there are some common use patterns.
1) You can store your secrets in code in your SCM IF they are encrypted... But this still results in the same problem, you still need to deliver a secret securely at deploy time (or have it available at startup) to be able to decrypt the secrets (password, credentials, secrets, certs) that have been deployed. That is where the Secrets Management Tool (such a Vault) comes in. The tool will allow you to securely retrieve your secret for use in decryption of the secrets when it's needed.
2) The other way as mentioned above is. Is to actually store all secrets, certs etc. outside of the SCM in the Secret Management Tool itself and retrieve them at deploy / startup time.
Obviously there are pros and cons to doing things either way. i.e. the first approach reduces complexity as you only manage one or two secrets at any given time. On the other hand, if you store all secrets in a vault, the potential for compromises associated with your entire ecosystem is reduced, as access to a single secret doesn't allow someone access to every other secret.
At the end of the day it all comes down to your use case / the security constructs available and of course the people you are surrounded with. Because at the end of the day, someone, somewhere needs to know a secret...
Yes. There is a recommendation. It is the usage of Cloud Vault. Take a look on some good examples:
https://www.hashicorp.com/blog/vault.html
https://blog.keepersecurity.com/2016/08/16/keeper-for-devops-more-than-just-passwords/
It's a kind of best practice to use a proper Security when it comes to credentials. As it can lead to Web Hack and other potential loss to the company.
Best way to do it to use Kind of Vault.
https://www.vaultproject.io/
https://docs.ansible.com/ansible/2.4/vault.html
AWS KMS
I am studying Authentication and Authorization protocols for my master thesis and I found that probably the best 2 alternatives are OpenID Connect and SAML 2.0 (actually, an European, SAML-based project in which my company was involved 4 years ago called SENSEI).
The purpose of the thesis is the extension of an existing Internet of Things system, which is basically a catalog of streams with information fetched from millions of sensors, and provide AAA (including Accounting), transforming it into an actual Marketplace of streams where people might pay to be subscribed to some streams.
So far, I think OpenID Connect will be a better choice over Sensei and SAML. Reasons are the huge amount of information, documentation, libraries and the companies which support this standard. Also is more developer-friendly and recent. However, I read the following paragraph written by OWASP in this article
While OpenId has taken most of the consumer market, SAML is often the
choice for enterprise applications. The reason for this is often that
there are few OpenId identity providers which are considered of
enterprise class (meaning that the way they validate the user identity
doesn't have high standards required for enterprise identity). It is
more common to see SAML being used inside of intranet websites,
sometimes even using a server from the intranet as the identity
provider.
So I was wondering if you, please, could help me with the following questions:
Do you think also that SAML is maybe more suitable for enterprise projects like mine? Is it true that OpenID is more user-oriented?
I have to think also about the Trust model regarding the sensors in order to be sure that they are reliable sources of information. Therefore, do you think it is a good idea to use the same protocol for: 1) the users who want to be logged in the system and 2) the devices which should prove they are trusted sources with non-faked data?
Related to the previous issue, if I could use OpenID Connect for devices, how could I make them to be authenticated without an email or password? I was thinking in the UUID as identifier but I was told it is not a good idea and also read the same on this StackOverflow thread.
Does anyone know if there exists any well-known protocol to handle or support Accounting in a system? As far as I know OpenID Connect supports Session Management but not Accounting at 100%.
Thanks in advance.
I'm not sure I can answer all your questions here... But I'll give it my best shot, based on my experience and knowledge. And, I'll say that you're being somewhat nebulous with the question (maybe you need to, so as not to expose you billion dollar idea). As such, my answer is really (admittedly) more likely to be considered a discussion point, maybe, than an "answer".
OIDC (OpenID Connect) is new, as is the IoT (Internet of Things). Enterprises are rarely bleeding edge, unless they are dragged into it kicking and screaming by a bigger enterprise partner. That being said, OIDC is built on top of OAuth2.0, so it has understanding out there, and enterprises are really in the take-up phase (IMO), and many of the purchased platforms (like my company's) support it at [current draft-1].
What I think is important to point out is that neither SAML or OIDC is "authentication". It's a standards-based method by which you can carry attributes from an authentication point to an application point that needs to KNOW who or what is connecting to it. Your users could connect one way, your "sensors" another. Or maybe both. Or maybe the opposite. If you're building the next trillion dollar social media site, do you want to limit the ways that your users can join up?
In reference to your question about OIDC and Sensors... I would suggest a certificate-based authentication system, if these things are truly just sitting out there on their own. Again, however, OIDC (and SAML) isn't an authentication system, really. It doesn't do the "front line" of the authentication - it provides a method by which an identity can be carried to the relying party based on a validated claim with a trusted partner. UUID may well be a good choice for the "username" of the device, but it certainly shouldn't be the "password".
Finally, I'm not quite sure what you're asking for with accounting. Are you wanting to charge a user for access to your IoT device streams with, say, microtransactions (interesting concept, if so). Again, neither SAML nor OIDC provide for something like this, at least as far as I am aware of. Accounting (and billing) would have to be built into the application.
HTH -- Andy
I am designing a web/mobile app that aggregates and customizably presents hobby/lifestyle-related data from 3rd party web services (Stage 1). If the site gains popularity, I plan to offer related sporting gear for sale (Stage 2).
I am relatively new to OpenID/OAuth and plan to use it for Stage 1 in much the same way Stackexchange does as security concerns are comparably low -- the user profile data does not contain any financials and mostly just contain user preferences that can easily be rebuilt. However, I am reluctant about using OpenID/OAuth for Stage 2 considering there will be financial and personal data.
Q1: Are there any examples of sites that successfully and safely implememt OpenID/OAuth while storing users' financial and personal data?
Q2: If the site only uses CC/PayPal data transiently, i.e. the user has to reenter the sensitive info upon each transaction, which is not stored, is the use of OpenID/OAuth more applicable and less risky?
Q3: Is it even possible to get an SSL certificate for this type of authentication/authorization architecture?
BONUS: Even if A1 is yes (or the technology hypothetically evolves into being applicable), do you anticipate that the end users will not trust a site that outsources authentication with their financial data (this is more of a psychological question)?
RELATED:
What reasons are there NOT to use OpenID?
OpenID Over SSL with self signed certificate
Google has OAuth/OpenID services and also store financial
information
For security reasons, you should have additional verification around
any sensitive information
SSL only verifies that when someone wants to reach your site, they
are actually reaching your site. OpenID and OAuth wouldn't impact
the ability toget an SSL Certificate
I'm developping a web site for a broker (JSF 2 + richfaces + oracle 10g), and i wanted to have your opinion concerning HTTPS (because i think it's not necessary in my case, since the user won't give any important details).
So:
to enter the web site, the user has to authenticate himself (using JAAS)
there's a page showing Stock Market data (it's financial data, so it's not that important)
the user can buy/sell stocks : he gives quantity, price, the account ( not bank account) for which he will buy/sell
the user can see his accounts, what stocks he has, past operations, etc....
Is it necessary to use SSL in my case ?
Yes, it sure sounds like it. Authentication usually involves sending a username/password combination to the server. That should never be done in clear text, so that requirement alone would make SSL a good idea. Furthermore, buying and selling stocks sounds like something that you would want to do in a secure manner.
I don't even understand what your concern is. Having an SSL protected website does not mean that you have to write a single line of code. It's just a question of buying an ssl certificate and configuring your web server.
I think it is necessary indeed, as it involves real money. Even if the user doesn't give away any details, there still can be man-in-the-middle attacks between the user and your server, which would enable anybody to gain access to the server with his credentials.
If it doesn't involve real money (it's not clearly written out), then you won't necessarily need it.
If the user is passing anything sensitive (and I'd say the number for a stock trading account is hugely sensitive) then HTTPS is crucial, in my opinion.
The way I'm seeing what you described, you have a user identifying himself/herself, and then you're passing basically all the info about his/her account over the web. Definitely secure that as much as possible.
There is not "good" way to get authentication tokens securly (in your case passwords) without using HTTPS or a one-time-password system.
In any case, I would sure want this type of access to be HTTPS secured else I might not trust it.
I've been given the task of finding and evaluating some authentication libraries for use in one of our products and one of the selling features being pushed by some solutions is "two-factor authentication".
What is this method and how does it work? Are there better methods (such as three-factor authentication, I guess)?
Two factor authentication is using two factors to authenticate a person (or sometimes a process).
This might be a PIN number (something you know) and a debit card (something you have).
There are many authentication factors that might be used:
Authentication factors apply for a
special procedure of authenticating a
person as an individual with
definitively granted access rights.
There are different factor types for
authentication:
Human factors are inherently bound to the individual, for example
biometrics ("Something you are").
Personal factors are otherwise mentally or physically allocated to
the individual as for example learned
code numbers. ("Something you know")
Technical factors are bound to physical means as for example a pass,
an ID card or a token. ("Something you
have")
From wikipedia.
Which factors you choose depend on the type of access required, security needed, cost, and especially what people are willing to put up with.
People get irritated with strong passwords that change every 4 months, so you might find employees happier with laptops that have fingerprint scanners and they can use a weak password and a fingerprint - two factor authentication may be easier for users.
But others might not like the privacy implications of biometric security and would rather carry around a keychain device that produces numbers which are typed in along with a password.
High security situations may require all three factors - something you have such as a card, something you are such as retinal imaging, and something you know such as a password.
But the costs and irritation go up as you add more levels.
-Adam
"Are there better methods (such as three-factor authentication, I guess)?"
The issue isn't simply more factors. It's a better mix of factors.
Passwords are easily lost and compromised. People write them on stickies and put them on the bottom of their keyboards.
Other non-password factors are part of the mix. For browser-based apps, you can use IP address, and other PC-specific material that floats in as part of the HTTP headers. For desktop apps (like VPN connections) independent key generators or plug-in USB readers might provide additional factors.
Its when two (or more) different factors are used in conjunction to authenticate someone.
For example, a bank might ask you for your account number and pin number. And sometimes, like when you call call centers, they might ask you for additional factors such as name, dob, phone number, address etc.
The theory is that the more factors you can authenticate against, the higher the probability that you are dealing with the correct person. How well it works and how much more secure it is is debatable in my opinion...
Factors include:
Human factors are inherently bound to the individual, for example
biometrics ("Something you are").
Personal factors are otherwise mentally or physically allocated to
the individual as for example learned
code numbers. ("Something you know")
Technical factors are bound to physical means as for example a pass,
an ID card or a token. ("Something
you have")
See: http://en.wikipedia.org/wiki/Two-factor_authentication
I'll take this from a completely different tact. All these answers are correct, of course, but I want to broaden the topic a bit - to think about where & when to apply two-factor authentication. There are three areas where strong authentication can be used: session authentication, mutual authentication and transaction authentication. Session auth is what most people think about when they think about 2FA. But imagine if people only had to use an OTP when making a banking transaction. The attack surface goes from "when logged in" to "When making a transaction", which is much smaller. if the transaction authentication uses a public key system to sign the tx, then all the better.
Mutual authentication is some system that attempts to thwart MiTM attacks. You can think of the little pictures some banking sites use, but they are totally ineffectual because there is no crypto involved. here's how we do mutual auth, by validating the site's ssl cert for the user: http://www.wikidsystems.com/learn-more/technology/mutual_authentication/. There are other ways to do the same thing, of course.