Disclaimer - I'm a non-coder, willing to learn, but have a question about SFTP.
So my developer whom I hired, provided me with a PPK file to login into my server. Is this a preferable way for FTP authentication?
I'm wondering because - What if I want to hire another developer to work on my site - now two developers will have the PPK file, right? So, how do I protect myself from previous developers having access to my site after they are finished? What is the proper process for these types of things?
Thank you!
You've been given a private key, needed to login to the server using key-based authentication. The key is not sent to the server, but it is used during SSH handshake. You are right that the key should remain private and you should not give it here and there. In general it would be a good idea to create your own keypair and place new public key to the server (and keep the private key with you). You will find more information about SSH authentication in this article. If you post your question to Superuser.com or Serverfault.com, you will get (find existing or ask for) more detailed instructions for non-programmer.
Every developer you hire should be given access to the site through a personal (individual) SFTP profile. Therefore each one of them will have his own PPK file. And when you want to revoke one of their accesses, just remove that developer's personal key from the server side configuration and he/she won't be able to log in again.
Related
I need a little guidance on how to implement signing of documents in a web based document distribution system we are developing.
At its simplest, user A will be logging into the website and create a Data Package. Word/Pdfs can be added to the package. User A will sign this document(s) using a digital certificate. User A might assign this to other users for reviewing the documents. They may sign the documents as well.
Now I know how to digitally sign data with C#. What I don't know is how to generate a certificate when each user logs into the website. The site is secured with DigiCert certificate.
What approach should I take to generate a digital certificate for each user? Once I have a .pfx file I believe I can store it in the database and use that.. Any guidance on this matter will be greatly appreciated!
thanks
I take to generate a digital certificate for each user? Once I have a .pfx file I believe I can store it in the database and use that..
This is what I call "naive approach" (read simplistic). You consider to store (maybe even generate) keypairs for the users in a web application. The biggest isssue with this approach is that someone with low-level access to the system (admins) or if database is leakt could gain access to the user's private key. To have a secure solution (considering signing), the private key may not leave its user
Doing everything in a web environment, you may consider using SubtleCrypto or other client site libraries, however at this point of time I see no reasonable way to manage the keys for pure web apps. Maybe you can store the user's keys and certificate in a localStorage, but it leaves some space for mallignant scripts to leak the keys.
Many real life secure solutions are working with secure modules (e. g. crypo cards), unfortunatelly the web libraries have no access to the modules (usually exposed as pkcs11 interface). As a solution usually the signing piece runs as custom code on user's computer. Before it was ActiveX, Applet,.. now it is often a "driver" exposed as a web server bound to "localhost" so the signig service can be used as web api from web applications.
Scenario:
I have a ASP.Net / Silverlight website with webservices for supporting the Silverlight apps with data. The website uses forms authentication, and thus the webservices can also authenticate requests.
Now I would like to pull some data from this system to a Android application. I could implement code for running the forms login, and storing the authentication cookie, but it would actually be much simpler to send the username and password in the webservice url and authenticate each call. I don't really see a big problem with this as the communication is SSL encrypted, but I'm open to be conviced otherwise ;)
What do you think ? Bad idea / not so bad idea ?
Conclusion:
After reviewing the answers the only really valid argument against name / pass in the url request string is that it's stored in the server log files. Granted it's my server and if that server is hacked the the data it stores will also be hacked, but I still don't like passwords showing up in logs. (Thats why they are stored salted and encrypted)
Solution:
I will post the username and passord with the request. Minimal extra work, and more secure.
See Are querystring parameters secure in HTTPS (HTTP + SSL)?
Everything will be encrypted, but the URLs, along with the query string (and thus the passwords) will show up in the server log files.
Bad Idea: The contents of your post are encrypted and though the URL parameters may be encrypted as well, they could still be visible to third-party trackers, server logs or some other monitoring software that can directly sniff your traffic. It is just not a good idea to open up a potential security hole in this way.
Users do tend to copy-and-paste URLs straight from their address bar into emails, blogs, etc., and save them in bookmarks, and so on.
And things like plugins, or even other software that reads, for example, window properties (alternate shells, theme managers, accessibility software) could end up with the info. And they might, for example, crash and automatically send crashdumps back to their developers.
And worms far less sophisticated than keloggers - like things that take screendumps - can get passwords this way. Sometimes even security software, for example if deployed in a corporate network.
And if the user has a local proxy, then they might be communicating in plaintext with the proxy which in turn is talking in SSL (not the way it's supposed to be done, but it happens).
And for these and more reasons, URLs with usernames and passwords, that used to be standard - such as ftp URLs with the username and password in the authority segment - are now typically forbidden by browsers.
https://www.rfc-editor.org/rfc/rfc3986#section-7.5
So, an emphatic NO, DO NOT DO THIS.
It is always good programing practice to not provide delicate info like username and password
in the URL. No matter how good a site is it can be compromised. So why provide with more info?
Suppose I have a valid (i.e. signed by one of the commonly trusted authorities) cryptographic certificate on my server. I could obviously use it to establish https sessions and deliver the contents with confidentiality (only the endpoints can read them), authentication (both endpoints know who they're talking to) and reliability (the message can't be tampered).
Now suppose that I actually don't care about the first two but, instead, I just the need the last one. For example, let's say I have a static resource that I would like to sign (a-la PGP) so that I can give it to other untrusted hosts: if my certificate is public and the resource has been signed with it, any client should be able to verify that the resource has not been tampered (e.g. by the untrusted host).
The question now is: is there a standard way to statically sign a web page? (I obviously mean something builtin in all browsers) I'm aware of someone (Unhosted) who's trying to accomplish something like this by implementing much of the logic via Javascript but still I'm wondering if a more standard way exists.
I'm not aware of any such standard implementation builtin in a browser.
Even in the mail area where such behavior is "standard" for long time (S/MIME), we find issues every other day with different clients, relays and servers.
For a download you may revert to sending a PKCS#7 container and associate a tool that unpacks and verifies. At least plugins and helper applications are availabel everywhere.
I'm also not aware of any standard implementation like that within a browser. But, to back up a bit... some things to consider:
For executable content (like downloaded EXE files, ActiveX controls, Windows Installer, etc.), a common / standard solution is Microsoft Authenticode. See http://www.tech-pro.net/code-signing-for-developers.html. Similar solutions for Java, Adobe, etc. The CA you buy the cert from will verify your identity. When you sign an EXE file with a cert from a trusted CA, Internet Explorer will display the signer information / less scary warning message. Same goes for UAC elevation prompts in Windows Vista/7. You're probably familiar with this?
But for the static content situation, the standard solution is SSL. May I ask why SSL isn't an acceptable solution in your application?
The problem I see is that there's no way for the user to verify the identity of the web page from the web browser, other than clicking the SSL "lock" icon in the browser to view the certificate. The new SSL EV certificates should verify that you control the domain in question, and that you are who you say you are (i.e. not be able to get a "PayPal" certificate for www.paypal.com.hacker.cz).
It sounds from your question that you're looking for an "Authenticode for web pages" sort of thing: a certificate with a subject not tied to a domain name and where the web page could go anywhere. Unfortunately, I'm not aware of any such thing for standard HTML files. I believe you can sign things like Adobe AIR applications, which can be based on HTML / Javascript / etc., although I'm not familiar with that platform. It does place the web page outside of the user's normal web browser, of course.
Oi, some vendor is telling my bosses that not encrypting the web.config is big security hole. This sounds like bunk to me. I mean, if someone compromises the server aren't we screwed anyways?
Like #Joelt suggested, ASP.NET had a security issue semi recently that allowed people to access files in the root web etc. Now, this issue could have existed for a long time. Alternatively, there could be a secret flaw right now that no one knows about except some leet punks ... which means we're all vulnerable right now. I mean, until the ASP.NET team (and security people a week or two before them) announced that previous flaw ... how long was that out in the wild? How many people exploited that?
So - that's the general idea. If for some reason a flaw exists - where people can remotely gain access to files - including web.config - then your data could be known.
Now - the kicker is this. So .. someone might find out about my DB name, DB ip addy and DB password .. right? but they need to access my internal DB ... so good luck there. BUT, my web.config might have my twitter username password in there? (Ding! light just turned on). My 3rd party api username/passwords. etc.
THAT is where the real security issue lies, IMO.
I'd hate it if u learn my companies twitter username/password and then start defacing our twitter account.
The encryption does not mean that you are protected. The private key needed for decryption is stored on the server, so if your server is compromised your web.config can be decrypted.
We only encrypt the connection string section of the web.config. It helps prevent other prying eyes from easily accessing our connection strings especially in the development environment (which is often much less secure than your production environments).
The encryption is just a small piece to the layered security. It is by no means an end-all solution for protecting your sensitive information.
There was a recently released security hole in ASP.net that would have allowed a remote user to access any file in the web root, including web.config, without accessing the entire server. Additionally, there may be login information in the web.config that allows compromising one server to compromise another.
Sort of. In my case, I host on a shared hosting account. So a lot of people have access to my account and the files stored there.
Personally, I don't worry about it too much. But, if someone had a mind to, they could access that information. And even if you own the server, if it's a company then there could be a lot of people who have access to it.
For critical data, encrypting it makes sense.
We've recently released the latest version of our intranet application, which now uses windows authentication as standard, and needs to be able to connect to a configured SQL server with the end-user's domain credentials.
Lately we've found that on a couple of customer deployments, although IIS can see the user's domain credentials, it will not pass these on to SQL server. Instead, it seems to use the anonymous account. This is in spite of following all the correct steps (changing the directory security to Win Auth, updating Web.Config to use Win Auth and denying anonymous users).
I've been doing a lot of reading that suggests we need to make sure that Kerberos is in place, but I'm not sure (a) how valid this is (i.e. is it really a requirement?) or (b) how to go about investigating if it's set up or how to go about setting it up.
We're in a situation where we need to be able to either configure IIS or the application to work for the customer, or explain to the customer exactly what they need to do to get it working.
We've managed to reproduce this on our internal network with a test SQL server and a developer's IIS box, so we're going to mess around with this set up and see if we can come up with a solution, but if anyone has any bright ideas, I'd be most happy to hear them!
I'd especially like to hear people's thoughts or advice in terms of Kerberos. Is this a requirement, and if it is, how do I outline to customers how it should be configured?
Oh, and I've also seen a couple of people mention the 'classic one-hop rule' for domains and passing windows credentials around, but I don't know how much weight this actually holds?
Thanks!
Matt
This is called the Double-Hop Problem and prohibits the forwarding of user's credentials to third parties. This occurs when they browse from one machine, against a site on another (first hop), and forwarding the credentials to a third machine (second hop).
The problem will not appear if you host IIS and SQL Server on the same machine.
There's alot more technical details published on this at How to use the System.DirectoryServices namespace in ASP.NET, which explains the double-hop issue, and primary and secondary tokens.
To run your application under the user's Active Directory or Windows credentials, ensure these:
the IIS application is set to NOT allow anonymous access
the IIS application uses Integrated Windows authentication
your connection string should have Integrated Security=SSPI to ensure the user's Windows/AD credentials are passed to SQL Server.
i.e. Data Source=myServerAddress;Initial Catalog=myDataBase;Integrated Security=SSPI;
You state you're not sure "how to go about investigating if it's set up or how to go about setting it up".
For this I'd heartily recommend a tool called DelegConfig. It's a very handy app that you can tell you if kerberos is setup properly.
Unzip it into a directory, configure a virtual directory in IIS to point to it. Browse to the main page and you tell it which backend server you want to allow access to (e.g. UNC, SQL, HTTP etc..) and it tell you its setup correctly or not and explain why.
It even has the abilty to recongiure the kerberos to fix the issue if you so desire (although I've not used this - I'd rather reconfiguire it myself to understand what I've done in future)
I realise this comes too late for your particular problem but thought it worth sharing for others that follow - especially the tools ability to explain why delegation is or is not working. I've found it invaluble.