I am trying to send an email using gmail smtp server. As the from address and password is needed for authentication, I have to set the same in web.config. And I wish the same to be in an encrypted format.
Ofcourse I am able to encrypt the values using' C:\Program Files (x86)\Ektron\CMS400v(x)\Utilities\ EncryptEmailPassword.exe' and so that I can set the values as encrypted form in Web.config file.
But how can I decrypt the values to its original form in code behind for the smtp server to authenticate.
I understand that you want to encrypt login and password stored in Web.config, best way to use it implemented in asp.net mechanism for that rather then Ektron.
Here you have an example how to do it on connectionstring but you can use any section to encrypt just change connectionstring parameter to something else.
http://msdn.microsoft.com/en-us/library/dtkwfdky.aspx
Short of de-compiling the Ektron code to obtain the keys, the encrypted text cannot be decrypted.
The Ektron encryption and app settings are for using the Ektron API to send emails. You don't need to decrypt because the Ektron library will do it for you.
As #Cezary states, one option is to not use Ektron email API and use ASP.Net.
Related
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.
Looking here: https://msdn.microsoft.com/en-us/library/dtkwfdky.aspx
They encrypt the machineKey in the web.config as well as the ConnectionStrings.
Is this because, when using a custom machineKey per site, it will use the machine key to encrypt the connection string?
Or is the machine key just used for view state encryption? And therefore it's prudent to encrypt it to help protect the application?
MachineKey is used only to encrypt/decrypt/validate ASP.NET cookies and anti forgery tokens and it handles mostly USER data related security. MachineKey has nothing to do with decrypting configuration values. ASP.NET will not use MachineKey to decrypt connection string.
Infact MachineKey is as sensitive as connection string, because after obtaining it, someone can easily create an authenticated cookie which will allow them to login to any user. That's why it should be encrypted.
You have to encrypt MachineKey by yourself.
I am currently working on a project in which I am rewriting an old (late 1990s) web application in ASP.NET. Part of this application is a user authentication system, which is used to access a couple of pages on the site. The user credentials (username, password, etc.) are stored in a database table.
This is all pretty standard, but while working with this database I found, to my horror, that this data is stored in plaintext.
I am wondering what the best way would be to improve the security of this insecure system. Is there an easy method of taking the plaintext data, encrypting (or hashing) it, and reinserting it? Can I use .NET Forms Authentication to facilitate any of this, and is it a good option for user authentication in the new app?
Thanks!
If you are on a Windows network, I'd use Windows Auth, which uses Active Directory. That would allow your Systems Admin group/person to administer who has access to the application.
Forms Auth is a good idea if Windows Auth won't work for you.
If they won't give you the time to implement either of the auth frameworks, I'd definitely encrypt the passwords on the database. Write a Console app and encrypt the passwords using information found here: Encrypt and decrypt a string
Then you'd need to modify your existing app to check encrypted passwords instead of plaintext ones.
I want to make my ASP.Net site authentication seamless using Ajax call.
So I consider using client side authentication service of microsoft that should be used via HTTPS because it sends username and password in plain-text format.
And the problem is that I can't use SSL in my site.
So I found a way to hash data before passing to web service that is described here
but the problem is there is a salt in DB that should passed to client for creating hashed password (that equals to DB saved password). and this is not safe.
Is there a better way for doing that?
I found a way.
We will use RSA for encrypting username ans password.
in summery I'll have a web service that creates RSA keypair and save it (this key will be regenerated every day to be more secure).
I will have a textbox or hidden field that calls this service and get the public key.
the for encrypt username and password with jCryption library client side and pass this to my authentication service using ajax call.
so the server will decrypt them with private key and the authenticate user.
I found a way.
Check this out: Secure AJAX Authentication without SSL
Just in case you were looking for an ASP.NET version of jCryption for bi-directional communication, which you mentioned you tried, you can find one on GitHub here: jCryptionNET
I have a web application developed in .net 3.5, and a SQL Server database.
Current auth method is a connection string in web.config, it seems like a good idea to move the authentication details out of plain text.
So, I have two questions:
Trusted Connection - The password policy here is strict, requiring frequent changes. Does this mean i'll have to update the password for the website every time it expires?
Is there another/better option?
As an alternative to trusted connection you can look at this set of articles on how to encrypt your web.config.
In brief, if you invoke from command-line
aspnet_regiis -pe "connectionStrings" -app "/SampleApplication" -prov "RsaProtectedConfigurationProvider"
section connectionStrings in the web.config of application SampleApplication from the default site will be encrypted using RSA.
I think putting the username/password is better simply because I don't want the user that runs my IIS server to have access to lots of databases. I would prefer to have it be focused, to where, for this application there is a user and that user has only access to this database.
You do need to be certain that your web.config file is secure, so you do need security on that.
If you want more security you could just use a dependency injection framework, and inject the compiled class that has the username/password, and just use that connection string. This class could be obfuscated, if you want some semblance of more security.
No, you won't have to keep changing the trusted connection details. You don't store the password there, so password changes won't affect you. (This is if you're using Basic Authentication, getting the users to connect to the SQL box as themselves)
But - if your application pool is running as a particular user, and that user has its password changed, you'll need to update that. You could consider having a user whose password doesn't expire for this.
Trusted connection isn't an option? A frequently changing password shouldn't be a limiting factor in your decision, since it's trusted you don't have to enter a password.
Another alternative is encrypting the connection string.