how to encrypt soap message in silverlight.. i am currently looking for ideas... as silverlight doesn't support WCF Message Security..
i have gone through a post by Peter Bromberg but it is also not discussing the idea about when how to exchange public/private keys or sort of...
The approach discussed in the post doesn't appear to do any asymmetric key exchange (as TLS does). Instead it relies on a symmetric key that is generated based on some assembly metadata. See the last paragraph of the article:
In closing, let me just address a couple of concerns: First, nowhere here do I say that this is "better" than SSL. I provide it only as an alternative. Second, the fact that the password or other component of the generated cryptographic key may be shown in plaintext in the code is not useful to a hacker, as both the password and the hash (both of which can be generated only at runtime) are required for a valid key. The download reflects the change to using the FullName property of the assembly to generate the salt value, and the ManifestModule.Name.GetHashCode() for the password, as discussed earlier.
It's not a very strong key generation mechanism as an attacker could simply download the same Silverlight application fire up a debugger and get the key. However it will protect any man-in-the-middle attacks where the attacker only has access to your HTTP traffic.
Personally I'd stick with SSL, with a self signed certificate if the goal is to have a free solution.
How about using transport-layer security? ssl?
Related
We have an automation platform that needs to store service account passwords in a database.
These passwords are used in a variety of different cases but generally need to be reversed into their original plain text form in order to be functional.
The service accounts are all compartmentalized to do very specific things - however, I'm uncomfortable leaving them in the database in plain text.
What is the best method/technique for storing passwords in a database when they need to be reversible?
For specific recommendations the platform is using C#, .Net MVC, and MySQL (MariaDB).
My immediate plan would be to store them after signing them with a non-exportable private key held in the local key store on the application server. Then reversing the encryption method when reading them out of the database.
If this is the technique I should be using are there particular methods I should be aware of?
Thank you for any help or information.
[Edited To Re-Open and remove the "Opinion Based" classification. Microsoft had particular documentation for this exact use case. I can't add an answer or mark as answered until it is but my solution is as follows:]
The recommendation from the Microsoft Engineering team was to use the Machine Key class and methods.
Utilizing a machine key set and generated via IIS and a uniquely generated "purposes" string provided to the Protect method I can securely encrypt and decrypt a column and leave it secure while at rest.
In MariaDB (MySQL) you'll need to use a column of tinyblob to store the byte array.
I don't believe this is an opinion based answer since this is the defacto way to do it with the technologies specified in the question.
Usually, to perform activities on behalf of a user with another service provider, you would use a scheme like OAuth2.
In this case, I assume this is not available or provided.
The issue with encrypting passwords as compared to hashing them is that encryption is a two-way function, it can be reversed, and this is in itself a security issue, since anyone with the key can decrypt the password. The issue then becomes how do I keep the key safe?
The answer is simple: Don't keep the key anywhere on your system.
Use your own users password to derive an encryption key, and then use this to encrypt their other passwords that you are storing for use with other services. When you need these passwords, the user must provide their "master" password to authorize the action
This has the benefit that if your database was compromised, no passwords would be recoverable. Additionally, if your front facing server was compromised, the only attack vector would be to modify the behaviour and wait for users to attempt to login.
From a more technical point of view, do the following:
When a user creates an account with you, derive a key from their password (PBKDF2 is a good choice). Let's call this k1.
Randomly generate another symmetric key, let's call this k2.
Encrypt all external passwords for other services with k2, which you can get each time by deriving k1 again and then decrypting.
If the user wants to change their account password, simply decrypt k2 with the old k1, derive a new key from their new password, and encrypt k2 again with the new key.
You should really avoid storing user passwords in a form that is reversible. But if you absolutely have to, the above is a good approach that keeps things relatively secure.
I am currently trying to undertand how best to implement signing/verification in a .NET 4.0 C# environment.
My requirment is to be able to sign data within my system as one 'user', at some point later that data needs to be verified by a consumer.
To accomplish this I am trying to use Certificates, however this is where I begin to struggle. One aspect of my confusion is that I have been advised I can use DPAPI for certificate management, however from reading DPAPI documentation it appears to only offer a way of protecting/unprotecting arbirary data for the local host/user. Although this data may happen to be a private key, it does not specifically deal with certificates.
A first question is, doe DPAPI in any way link to the local certificate store, or other certificate management solution?
The hope was that the code would not have to locate certificates, instead simply pass the data down to a helpful API where it is either signed (on the data source) or verified (on the consumer).
Any comments are appreciated.
DPAPI is used to encrypt data that is intended to be decrypted only under the same Windows user account. It uses a symmetric encryption algorithm, so it cannot offer the signing functionality that you require.
If you wish to offer signing capabilities, then use of an signing algorithm based on a public-private key pair (with the public key distributed in a certificate) would usually be the appropriate approach. The .NET BCL does offer functionality for the signing and verification parts (including use of keys from the local certificate store), but it won't help you with the key distribution side of things.
I have a password in my code which is needed to connect to a sftp server. Whats the best way to "obfuscate" or hide it in the code?
Thanks
Don't store you password in your source code, store it in a protected section within you App.Config (or Web.Config).
See Encrypting Configuration File Sections Using Protected Configuration section in this Microsoft Doc
This works by encrypting the encryption keys using built-in Windows stuff, locked to the MAC address and various other undocumented things.
This will even work if you are using more than one server:
... if you are planning to use the same encrypted configuration file on multiple servers, such as a Web farm, only the RsaProtectedConfigurationProvider enables you to export the encryption keys used to encrypt the data and import them on another server.
Using this, if someone wanted to get your password, they would have to first break the Windows security on your server (not impossible, but harder than looking into your IL for the password by far).
I actually consider using the "protected sections" feature in App.Config or Web.Config to be LESS secure than storing the password in your code.
Anyone with server access can decrypt that section of the config just as quick as you encrypted it by running the decrypt command described in the article everyone keeps quoting:
aspnet_regiis -pd "connectionStrings" -app "/SampleApplication"
https://msdn.microsoft.com/en-us/library/zhhddkxy.aspx#Anchor_1
So this feature of ASP.Net only adds security in the case that a hacker somehow had access to your web.config but not your entire server (happened in 2010 as #djteller mentioned in the oracle padding attack comment). But if they do have server access, you're exposed in one cmd call. They don't even have to install ildasm.exe.
However, storing actual passwords in your code is a maintenance nightmare. So one thing I've seen done is storing an encrypted password in your web.config and storing the encryption key in your code. This accomplishes the goal of hiding passwords from casual browsing while still being maintainable.
In this case a hacker has to at least decompile your code, find your key, and then figure out what encryption algorithm you're using. Not impossible, but certainly harder than running "aspnet_regiis -pd...".
Meanwhile I am also looking for better answers to this six year old question...
Don't bother.
Anything you can do, your attacker can trivially undo.
If it only needs to run on a single machine, however, you can use the ProtectedData class, which will protect it securely against anyone not on that machine and/or user.
In general, the only remotely secure way to do this is to store the key in a separate, secure, location.
For example, you can encrypt it using a (non-MD5) hash of a password, then require the user to enter the password so that you can get the hash. (The hash and password themselves would not be stored anywhere; you should make a separate hash to verify the password)
Best way is don't!
Failing that:
Encrypting Configuration File Sections Using Protected Configuration
There are no "best way" to store password in source code since it can be recovered in many ways.
You can obfuscate password string or even encrypt it to prevent reveal thru simple viewing but it can't be treated as serious protection.
You can put it as an encrypted value in the web.config file. It doesn't look too hard:
K scott Allen tutorial http://odetocode.com/blogs/scott/archive/2006/01/08/encrypting-custom-configuration-sections.aspx
I think there's a Scott gu blog post with links to other information.
http://weblogs.asp.net/scottgu/archive/2006/01/09/434893.aspx
Encrypt it with something strong like AES, but as implied by SLaks, your attacker can reverse engineer your code and work out the encryption method and key. All you are doing is adding a layer which keeps script kiddies and a certain level of attacker out. Someone who really wants to work it out, can do. They could also run your program and watch what password is sent.
Don't save your password in the source code.
Read this:
http://en.wikipedia.org/wiki/Security_through_obscurity
There is no good way.
All you can do is use a smart algorithm to encrypt the password.
An experienced reverse engineer would manage to crack it.
There's not much you can do against someone who really wants your password. However, if this isn't a public app (intranet? in-house app or something) you could simply encrypt it using a symmetric encryption algorithm, or do something like base 64 encoding it.
You could also run an obfuscator over your code to make it less obvious that there is a password in there somewhere.
Do you have another option? Raw SFTP access is kinda dangerous, maybe you can create some sort of proxy service in between, which only allows the specific actions your app requires. Storing the password for that service in your code is a not as risky as storing your SFTP password in your code.
You could use something like SLP Code Protector to block reverse engineering of your assemblies. Still, I agree with everyone else, it's not the best idea.
I don't want to use SSL to encrypt signup and signin forms for a website I'm building.
I don't have money to pay for a certificate.
I need to use encryption with jQuery and decryption with C# in my asp.net website.
Does someone have an example and how is it secure to adopt this method?
If you're not using SSL, then you're not secure, but that's not the only reason.
SSL protects the actual communication, whereas encryption protects the data you are communicating. You should not even be encrypting the passwords at all. You should be making a hardened hash of the information. A hash is a one-way function (cannot be reversed), whereas encryption is two-way function(can be reversed). Hash hardening and use includes:
Iterating over a hash built for speed, such as SHA512 a couple of thousand times or using something like BCrypt.
Use a salt - Something like a 64-bit array of jumble per user, stored in the database will do it
Encrypt the keys and salts in the DB using a key in the application layer - This means if your database is taken, they would still need the key from the application layer to access the raw hash information, as well as the salts.
You have to remember that security is built in layers. By skipping SSL, you're skipping a large portion of it. At the very least you can use makecert to create a self-signed certificate. All that will happen is that the user will be warned about it. A good SSL certificate can cost as little as $12.99 on GoDaddy. I recommend getting one as well as implementing the above.
You can do SSL without paying for a certificate, and this method get you secure only browser get information about your certificate is not qualified.
Read about this http://www.akadia.com/services/ssh_test_certificate.html
It's probably not secure at all.
SSL really is the way to go; if you can't afford a certificate, you can always make your own. Obviously those won't validate up to one of the trusted root authorities, but they are just as secure - the identity of your website will not be confirmed by a trusted third party, but the connection itself will be just as securely encrypted.
By not using SSL you're opening up your code to network sniffing attacks. Encrypting on the client side won't do any good either.
Unfortunately there's no safe way around it without getting a valid certificate. This approach would be unsecure.
I agree with the security concerns of the other individuals, if you're hell-bent-for-leather on doing it this way, you may attempt to employ a custom PKI interface. You will have to research a little more deeply on the code necessary to accomplish this but here is a link to describe the public key structure:
Public Key Cryptography
So if you manage to code up a public key RSA algorithm in jquery, you should be to match its private key decryption in C# without difficulty. This is not a recommendation because this really is only "security through obfuscation" (which is not security at all).
You can encrypt the form data with Javascript. This can be done, see http://www.movable-type.co.uk/scripts/aes.html. If data is encrypted with a key, then you'll have to store that key in javascript code and also in server-side code. Since javascript code will be client-side and key will be public, that's not secure at all :). The same is also valid for asymmetric encryption. Different data can be encrypted with the same key and sent to server.
SSL is designed to overcome security problems on the web, using public key cryptograpy and symmetric encryption tehcniques. Middle-man attack is prevented. Using SSL, you can be sure that your data is secure, not altered through the way and there is a 3rd party, certificate authority, which says that you're the person you claim to be.
If you say that I can put the key or encryption code in an applet or active-x or flash swf object and use obfuscation to secure the code, that may be a way. But again this approach is open to attacks and not secure. Obfuscation does not guarantee that your key or algorithm is safe, just hardens the cracker's job to get the key.
I hope that helps.
You could use a HMAC for authentication. This would not provide privacy but a sniffer (guy looking into then network traffic) would not be able to get the passwords nor login impersonating an authentic user. When I it does not provide privacy I mean the sniffer will see all the transferred content but not the password.
SSL is of course very secure, but an overkill for many applications.
I've been reading a little about encryption recently and am interested in protecting a licence file from tampering. Now this may not be the best way to do it, in which case I'm open to suggestions. But one way I was thinking of protecting it is to simply encrypt it.
However if I were to use encryption I'd need to use symmetric key, but this raises the question. If I store a key in the source code, with such tools as reflector, is it really worth it? It seems a fairly trivial task to obtain the initalization vector, salt, key etc and therefore break the encryption. Is there a way to protect a key in source? Or is this the completely wrong approach?
If you want to prevent tampering, you want signing/hashing, not encryption. Similar theory - but it means you can validate the file with the public key in the app, without requiring the private key that you keep on your server (and use to issue licenses).
Search for cryptographic hashing / signing.
Anything on the client side of the system can be compromised.
If you encrypt your file you must also somehow place the decryption key in your program. Anyone with a hex editor will be able to step through your code to find this key and then decrypt your license file and also create keys for your system.
Internet activation would be a good way to go, but I would see if you can find third parties to do this for you as they will have been down these roads before.
That said running your license file through some AES 256 encryption can't hurt :).
if you are speaking about MS/.NET environment, i recommend you the DPAPI.
It is an API used to store your data protected by a password. Then you can ask me "but then i have the same problem", the answer is no, because in this scenario you use a user password to protect your data. So what you have to do, to access your data, is run your application under a certain credentials. In MS environment, its the the best solution.
from the documentation:
DPAPI is focused on providing data protection for users. Since it requires a password to provide protection, the logical step is for DPAPI to use a user's logon password, which it does, in a way. DPAPI actually uses the user's logon credential. In a typical system, in which the user logs on with a password, the logon credential is simply a hash of the user's password. In a system in which the user logs on with a smart card, however, the credential would be different. To keep matters simple, we'll use the terms user password, logon password, or just password to refer to this credential.
What you're attempting is DRM; there is no 100% way to do this on current PC hardware. There are many measures you can take to obfuscate parts of your program. It's a tradeoff between how much you want to obfuscate and how many hurdles you want to make your paying customers go through.