I created a wcf service that serves up an image as a byte[]. I have it functioning fine, but I’m not that experienced with authentication and encryption in services. The client is going to be displaying the image in their site. They requested username and password authentication and some form of encryption, but they seem flexible if there is an easier option that works good. They will only be sending a few parameters in the call,
I’ve been modeling my attempt after this, but from what I’m seeing in wcf, it has to be over an SSL layer if you do it this way because there is no encryption for the plain text soap headers containing the username and pass. I would prefer not to go the SSL route unless it's necessary.
I read that I could use negotiateServiceCredential="false" for a one-way communication, but I'm not sure a one-shot security mode is what I'm looking for. I can't seem to find a tutorial or scenario example similar enough.
if anyone might be interested... I'm using this guy's solution to model off of link, and it seems to be working good.
Basically, after reading some other posts on here, I got turned on to this book. Where I learned some more about how these services are generally setup. I decided on going with username & password authentication by creating my own validator class for the message security. This tag was a little tricky for me to figure out (in the web.config) but there is a lot out there to learn more about it:
<userNameAuthentication userNamePasswordValidationMode="Custom" customUserNamePasswordValidatorType="YourService.MyValidator, YourService" />
If you use username for message security WCF requires you to secure the transport with a certificate, in this case an SSL. This is because the credentials are passed in plain text. The plus is that SSL hardware accelerators allow for fast message transmission, and I'm attempting to transport large files to the client.
The solution I linked to is a good walkthrough for any newbs like myself. A really helpful part was learning how to make temporary certificates to use for testing purposes using MakeCert. Just run this in a cmd:
makecert -r -pe -n "CN= compaq-jzp37md0 " -b 01/01/2000
-e 01/01/2050 -eku 1.3.6.1.5.5.7.3.1 -ss my -sr
localMachine -sky exchange -sp "Microsoft RSA SChannel Cryptographic Provider" -sy 12
Where “compaq-jzp37md0” is the server name so you need to replace with your PC name
Related
All,
I am trying to mount a NAS drive to a Linux VM.
I have a requirement to encrypt the data in transit, i.e. I want data to be encrypted when
its written from the Linux to the NAS dribe
https://www.dellemc.com/hu-hu/collaterals/unauth/technical-guides-support-information/products/storage/docu88304.pdf
As per the above link krb5p provides encryption of data.
krb5p: Kerberos authentication, data integrity, and data privacy by encrypting the data before sending it over the network. Data encryption requires additional
https://www.varonis.com/blog/kerberos-authentication-explained/
I understand how Kerberos mutual-authentication works but once access is granted to the service (in my case the NAS drive) how does the data transferred to the NAS gets encrypted.
Can someone provide additional details or documentation on how "encryption" works with krb5p?
I am unable to find any additional details.
As per:
https://whyistheinternetbroken.wordpress.com/tag/krb5p/
when using krb5p:
NFS packets will be encrypted with the enctype specified in the Kerberos configuration.
But what are the available enctype that can be specified?
I have attached a diagram that tries to explain the flow of messages b/w Server-KDC-Client
Kerberos allows mutual authentication between a client and a KDC, the KDC and a service, and a client and a service. This happens by way of key agreement between each party.
Client and KDC prove knowledge of a shared key, KDC and service prove knowledge of a different shared key, so client and service can generate yet another random key and agree with one another.
In other words when the client sends the ticket to the service it contains a secret key that both parties can use to encrypt data after authentication has succeeded. In this case that key is what is used to protect NFS traffic.
What enctype is selected is somewhat undefined. It's up to all three parties to agree on one, and each has an opportunity to change it. In practice it's up to the service to make the final decision though. It should be whatever it thinks the strongest algorithm the client can handle. This usually means RC4, AES128, or AES256.
Kerberos just provides the encryption key, but it doesn't magically perform the encryption itself – that has to be done by the NFS client and NFS server themselves. They are aware that krb5p was negotiated, and will call the corresponding encryption/decryption functions when needed. (More specifically, it happens in the SunRPC layer, which NFS is built on.)
When the Kerberos KDC issues you a ticket for "nfs/yourserver.example.com", that ticket includes two copies of a randomly generated session key: one copy decryptable by you, and the other copy decryptable by that server.
The KDC will mark this session key with the best enctype that is common between what was indicated in your ticket request, and what long-term keys are held by the server's principal. Usually this will be AES256-CTS, though it can be RC4 (arcfour) if the service key hasn't been changed in a very long time.
For example,
The "nfs/yourserver.example.com" principal has long-term keys for aes256-cts-sha1-96, aes128-cts-sha1-96, arcfour-hmac, des3-cbc.
Your client making the AS_REQ indicates support for aes256-cts-sha384, aes128-cts-sha256, aes256-cts-sha1-96, aes128-cts-sha1-96.
The KDC chooses aes256-cts-sha1-96 as the best enctype for the session key.
This indication is stored in the ticket itself. If the client is using MIT Krb5 software, you can use kvno to manually request a service ticket (if you don't have one yet) and then klist -e to see the enctypes set for that ticket – "skey" indicates the enctype that the session key is meant to be used with.
So after receiving the ticket from the KDC, you send it to the NFS server as part of the RPCSEC_GSS authentication process, and now both you and the server have copies of the session key. (The same session key remains in use for as long as the service ticket is valid – usually 10 hours.)
The set of possible enctypes is:
aes256-cts-hmac-sha384-192, aes128-cts-hmac-sha256-128: New, not supported by most implementations yet (and most services won't have keys of that type yet, either).
aes256-cts-hmac-sha1-96, aes128-cts-hmac-sha1-96: Widely supported by all Kerberos implementations.
camellia256-cts-cmac, camellia128-cts-cmac: Decent alternatives to AES, but rarely used in practice.
arcfour-hmac (RC4): Deprecated, but still occassionally used. Gone from Linux 5.10.
des3-cbc-sha1: Deprecated, but still implemented.
des-cbc-md5, des-cbc-crc: Completely obsolete. Hope you'll never see those.
(Don't believe webpages saying that Linux NFS client only supports DES – that was fixed in 2010 for v2.6.35, and AES is fully supported now.)
I edited this question to clarify why I asked this question again (I had weak Google-Fu and found these rather old 1 2 3 pretty-much-duplicates only after posting).
Approaches to accessing a password-protected resources that I've seen in the wild.
Plaintext storage in script (might often end up being shared, or in a Dropbox)
Plaintext storage in a config script
You can do password = readline("Password: ") but of course the password ends up in plaintext in the console (and thus in console logs etc.), so might as well store it in a plaintext config file.
I found this little trick to avoid displaying the password in the Terminal, but running system("stty -echo") on OS X Mavericks leads to the error stty: stdin isn't a terminal, so I guess it wouldn't be particularly portable.
Using tcltk. Has the unfortunate effect of making Rstudio crash and being difficult to install.
keychain. It's not on CRAN, so I don't think I can use this as a first-line approach, I'd also like a bit more detail about where and how passwords are stored on various systems (i.e. will it end up in plaintext on Windows?).
Access tokens, OAuth etc. seem to have similar problems.
I don't know any R packages which use PGP for connections? Probably also a bit difficult for newbie users.
I'm not asking for myself mainly, but I want to provide somewhat sensible defaults for nontechnical users who might store plaintext passwords enabling access to sensitive data in their Dropbox.
Unlike others who asked similar questions, I could also change the server-side of things if I had a better approach.
Are there best-practice approaches that I'm currently missing? My focus on interactive sessions is because I assume that's how most nontechnical types use R, but of course it would be nice if it worked during e.g. knitr report generation too.
Some suggestions to solve your problem securely. These solutions match all programming languages.
Establish a secure connection to your resource without R, like a SSL tunnel.
If you need a secure password in R to establish a secure connection, then you can read this from a secure config file and remove this password variable if you don't use the password anymore. A secure config file is a config file that is not part of your code repository (Git, SVN, ...). You have to manage your secret independent of your code. This mean separate your code and your secrets. One simple way is to put your private and secure secret in your private and secure user home directory. Then you have delegated your security problem to your operating system. Your secret is now save as your OS and your home directory. Pleas check the rights of your home directory and enable the file system encryption if they are off. Notice, this is the way like Maven handle passwords.
You get more security if you encrypt your password/secret config file. Then you have second line of defense.
For most applications is point 2 enough.
Notice, be sure that your secret is not deployed with your code. You need a second way to manage and deploy your secret to production systems.
Notice, be sure that if your programs jams, that your secret is not in memory anymore.
Notice, use always strong algorithms for encryption. Don't implement your own security algorithm, is a high complexity task. Better use standard implementations of strong encryption algorithms.
In an app, I Have a network server and clients.
After a handshake, let's say the client sends "userId sessionId SOME_COMMAND param param param".
I have already identified the client and the sessionId is checked on the server accordingly, so identity is no more an issue.
But I'd like to prevent a hacker to modify the message or create a false one, for example sending "userId sessionId SOME_COMMAND paramModified paramModified paramModified".
I thought about using a pair of private/public encryption keys, and send the hash of the message in the message itself. But since it's automated in the client program, I may have to send the public key during the handshake. So the hacker could simply retrieve it and generate the proper hash.
I could also use complex encryption seeds or algorithms, but my experience with hackers has shown me that they will decompile anything.
So the bottom line is: I can hide everything that runs on the server, but I can't hide anything on the client program. And I'd like to to forbid to modify the message that the client program is supposed to send.
I don't even know if it's possible. And I'm opened to any suggestion. And by the way, I'm using Java, although it should not be very relevant. Thanks.
Forget it. Use SSL like everybody else. There are complexities which you haven't even begun to address.
I wonder which class is the class that I use to encrypt data (first time string data) and the best method of encryption (among those supported by caché). Must generate a strong encryption for data in my project.
Any help is welcome.
If someone can show me some example, I'll be even more grateful.
Please state what exactly do you want to encrypt. To encrypt the whole database, there is a setting in System Management Portal, this encryption is certified in US. To encrypt data transfers, you may use SSH (see %Net.SSH.*), HTTPS (see %Net.HttpRequest with Https property), and Web Services with WS-Security (see documentation). To encrypt just any string internally, see $system.Encryption.Help().
We use ensemble web services to serve up Base64 encrypted XML payloads to web portals and mobile apps in the healthcare field. The code we've implemented looks something like the below snippet, in addition to some other security features related to the web service.
Set sc = ..xmlData.XMLExportToString(.xml)
Set xmlReturn = ##class(%System.Encryption).Base64Encode(xml)
Quit xmlReturn
I am responsible for several ASP.NET web apps running on a local Intranet server. Users outside the company aren't supposed to have access to the server, but I don't like leaving anything to chance if it's not necessary. And only admins should have access to the file system.
Should I encrypt the app settings and connection string sections of web.config? I haven't see this mentioned very often, and I was wondering if it's overkill or not a best-practice. I've got passwords in my connection strings and account info for a service account I use to query AD in the app settings.
BTW: I would encrypt using
Configuration webConfig = WebConfigurationManager.OpenWebConfiguration(System.Web.HttpContext.Current.Request.ApplicationPath);
ConfigurationSection section = webConfig.Sections["connectionStrings"];
if (section != null && !section.SectionInformation.IsProtected)
{
section.SectionInformation.ProtectSection("DataProtectionConfigurationProvider");
webConfig.Save();
}
Should I encrypt the app settings and connection string sections of web.config?
If the connection strings include passwords: then yes, there is no other reasonable option.
If using integrated security to connect to the database, then the information exposure would be database and server names, which is less of an issue. But might be easier to have a deployment rule of always encrypting, because the simpler rule is easier to follow and audit.
You can also use aspnet_regiis.exe to encrypt sections, rather than writing your own code. Enter aspnet_regiis.exe -? into a PowerShell (or cmd) prompt to see options.
I did something similar for encrypting my web.config file, and I don't regret it. Maintaining it isn't complicated, and it adds yet another layer of defense. Since security is built in layer, there's nothing wrong in doing that.