Encrypting Keystore Password in Jetty 10 - encryption

According to the jetty docs: https://www.eclipse.org/jetty/documentation/jetty-10/operations-guide/index.html#og-password if the keystore is password protected, I need to define that password in a configuration property in start.ini . The problem I'm running into is that I'm building that config from a script as part of the deployment process. If I'm going to be storing the password in a script, I need some way to encrypt it, otherwise it defeats the purpose of having a password in the first place.
Does anyone know if this is possible? The best I could find is obfuscation (OBF) which isn't much better than plain text from a security perspective. If not, how do I keep the keystore password secure?

Related

How to encrypt the DB password in Artifactory?

We have Artifactory OSS that currently use the default DB and we want to move to MS-SQL. According to the regular links - we need to write the MSSQL password in clear text in the db.properties file.
Can the password be encrypted somehow, so the Artifactory will know how to decrypt and use it
You should be able to activate encryption using the REST API. See the documented API.
This should create an encryption key and apply it on the db.properties where the username and password are stored.
I hope this helps.
What I found was that after switching to MS-SQL and starting Artifactory- Artifactory has encrypted the password.
In the admin->Security->Security Configuration there is a section for Password encryption that you can choose to encrypt all password in configuration files

ASP.NET Core appSettings.json security

I have an ASP.NET Core 2.0 WebAPI application that has Db ConnectionString in appSettings.json.
While in development it has this value:
"DefaultConnection":"Server=localhost;Database=Tyroll;Trusted_Connection=True;MultipleActiveResultSets=true"
and only when we publish it to production we change this with appropriate passwords, by using VS 2017 publish profile.
So SQL server passwords for are not stored on repository and no problem there.
The file appsettings.json is protected by IIS
The question I wonder is should this password be somehow 'hidden' even on IIS?
One reason being additional security, so that SQL credentials are not in plain text in case of breach here.
Another for some authorization scenario where IIS admin should not have directly access to SQL server.
I figure it could be encrypted and the app itself will have key for decrypting it. This would not be 100% secure since in the case of breach on IIS even this key could be reverse engineered from the app, but it would make it more difficult then when it's there in plain text.
So first question is should I be doing this at all?
And second if 1.Q is Yes, what would be the best / recommended way to do it?
Is there some built in tool for this in .NetCore2 or VS2017 or IIS, or some other tool?
Here are some related links:
reddit aspnet_core_appsettingsjson_security_question
stackoverflow is-appsettings-json-protected-by-iis
itprotoday passwords-webconfig
keeping-secrets-in-asp-net-core
I would suggest that you should user Active Directory Integrated security for accessing the database , the App Pool can run under the user account and that particular user account will only have the required access to the database . This safeguards the user credentials in case of an attack since the password is never exposed.
Solution I implemented is making custom encryption of Password in ConnectionString.
But since the App needs to the decrypt it, it is more an Obfuscation.
For encryption I have used AES (using System.Security.Cryptography) and the key is stored: half in connectionString itself and other half hardCoded in the Application.
In addition regex was used to extract Password from ConnectionString and then was replaced with decrypted string of it.

Encrypt password from client side using AES?

I want to encrypt the password sent from client side. I found crypto-js which provides AES implementation. My question is that if i use a "passphrase" for encryption, will anybody who can view the source of the page can also see my "passphrase" too ? If i have the wrong concept please help me clear it.
No, you cannot just read the password if it is not stored in JavaScript.
However, in almost any case where the JavaScript code can be read, the JavaScript code can also be changed. And if you cannot trust the code, then all bets are off - the password may be send to or retrieved from anywhere.
Take for instance an internet cafe. You connect to "coffeeplace.com" but you're actually logging on to a hoax service. In that case any unprotected connection can be altered. If the hoax service has obtained a rogue CA certificate then this is even true for HTTPS connections.
If you want to protect a password you should send it over a HTTPS connection. If you want application level security on top of the HTTPS transport security then you could encrypt the password using a public key; the server can then later decrypt it with a private key.
Application level security is useful if you want to store the password (hash) securily on your servers for instance. You could then later process the encrypted password using a service in the back-end.
To answer your actual question: Yes, everyone will see the passphrase.
But really, do some research on:
password hashing: Do you really need to know the plain text of user's passwords?
why using javascript for crypto is a really bad idea in almost all use cases.
Information security in it's whole
or please leave information security to people who know their turf. You are quite probable to introduce new problems, because crypto is hard, even with all the best intentions.

Encryption Web.config sections

I have read about aspnet_regiis for encrypting web.config sections in an ASP.net project, but I am confused how this works since the decryption key must live in plaintext on the actual server somewhere.
I would ideally like to use AES for encryption, but this requires adding the aes key to the web.config in plaintext itself, which seems useless to me. (from https://stackoverflow.com/a/8777147)
Perhaps I am missing something.. can someone explain how this encryption process is actually secure?
aspnet_regiis encryption is easy to decrypt if you are able to login to a session on the machine and have access to the key.
This protects against a scenario where someone can view the file but cannot login to the machine and a scenario where the decryption key is correctly ACL'ed to a known set of users.
Under the hood it uses DPAPI and machine context specific information. I believe you can also encrypt using a user profile in which case no other user can decrypt it.
Here are some useful links:
http://weblogs.asp.net/owscott/archive/2005/07/29/421063.aspx
http://weblogs.asp.net/scottgu/archive/2006/01/09/434893.aspx
You must create a key first and than use this key in your web.config
An detailed explanation can be found here: msdn microsoft
the one under web farm scenario's is the most practical.
I think it's useful to encrypt them if you have a lot of passwords etc. in the web.config.

Is there any way I can maintain password history of a user in ASP.Net application?

I need to view users password history in an ASP.net application.
Is there any way to achieve it?
You have to maintain that as an encrypted string in your backend. Meaning in the database or some file system (not recommended).
It depends.
In fact, storing plain passwords is the worst approach in terms of security.
Administrator must not have access to plain passwords, this the reason of most of applications prompts you to create a new one, because passwords are hashed and hashing prevents from reverting to plain text.
If you need to track passwords, you'll need to write a custom membership provider tracking them.
There is nothing built into .Net that will provide this information. You would have to write your own solution to create an audit trail of passwords but this would involve storing passwords in a visible format. Remember the massive caveat about plain passwords though!
So long as you're only doing this for old passwords i.e. storing them AFTER the user has set a new password it should be ok.

Resources