Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 11 years ago.
Improve this question
I'm currently setting up a commercial SFTP server and I'm just looking for some of your opinions on the set-up I'm currently thinking of implementing, as well as a recommendation as to what commercial Secure FTP server software would be best to suit. Bear in mind that the data i'm responsible for is highly sensitive so any comments/feedback is much appreciated.
Here's the scenario:
1) Before file upload, files are compressed & encrypted using AES 256 with a salt.
2) Files uploaded from the clients' server over SFTP (port 22) to our SFTP server.
3) Files are then downloaded over HTTPS by our other client using one time password verification (strong 10 char alphanumeric password)
The specifics of the implementation I'm thinking of are:
For part (2) above, the connection is opened using host key matching, public key authentication and a user name/password combination. The firewall at both sides is restricted to only allow the static IP of the client server to connect.
For part (3), the other client is supplied with a user name/password on a per user basis (for auditing) to log into their jailed account on the server. the encryption password for the file itself is supplied on a per file basis, so i'm trying to apply two modes of encryption at all times here (except when the files are resting on the server).
Along with dedicated firewalls on both sides, Access control on the SFTP server will be configured to block IP addresses with a certain number of failed attempts over a short time, invalid passwords attempts will lock out users, password policies will be implemented etc.
I like to think that I've covered as much as possible but I'd love to hear what you guys think about this implementation?
For the commercial server side of things, I've narrowed it down to GloalSCAPE SFTP w/ SSH & HTTP module or JSCAPE Secure FTP server - I'll be assessing the suitability of each over the weekend but if any of you have any experience with either i'd love to hear about it also.
Since the data is clearly both important and sensitive from your clients' perspectives, I'd suggest you consult a security professional. Home-grown solutions are typically a combination of over- and underkill, resulting in mechanisms that are both inefficient and insecure. Consider:
The files are pre-encrypted, so the only gain from SFTP/HTTPS is encryption of the session itself (e.g. login), but...
You're using PKI for upload and OTP for download, so there's no risk of exposing passwords, only user IDs -- is that significant to you?
How will you transmit the one-time passwords? Is the transmission secure?
Keep in mind that any lockout scheme should be temporary, otherwise a hacker can disable the entire system by locking each account.
Questions to ask yourself:
What am I protecting?
From whom am I protecting it?
What are the attack vectors?
What are the likelihoods and risks of a breach?
Once you've answered those questions, you'll have a better idea of the implementation.
In general:
Your choice of AES256 + salt is very reasonable.
Multi-factor authentication is probably better than multiple iterations of encryption. It's often thought of as "something you have, plus something you know," such as a certificate and a password, requiring both for access.
As far as available utilities, many off-the-shelf packages are both secure and easy to use. Look into OpenSSH, OpenVPN, and vsftp for starters.
Good luck - please let us know what method you choose!
So what's wrong with OpenSSH that comes with Linux and the BSDs?
Before file upload, files are compressed & encrypted using AES 256 with a salt.
This part rings some alarm bells...have you written some code to do this encryption/compression? How are you doing the key management? You also say your key is password derived, so your use of AES 256 and salt is giving you a false sense of security - your real key space is much less. Also the use of the term 'salt' is inappropriate here, which suggests further weaknesses.
You would be better off to use a well proven implementation (e.g. something like PGP or GPG).
Also, if you use PGP style public key encryption for the file itself (and decent key management), the security of your SFTP server will matter a lot less. Your files could be encrypted at rest.
The argument for the security of the rest of the system is very convoluted (lots of protocols, authentication schemes, and controls) - it would be a lot easier to secure the file robustly, then do best practices for the rest (which will matter a lot less and also be independent controls).
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 5 years ago.
Improve this question
There are lots of ways to create a login form for web apps and most of them are flawed one way or the other:
Passwords are transmitted/saved as clear text
The login dialogs are subject to XSS attacks or SQL injection
Is there an example or tutorial how to create a secure login form?
I agree with Carlos about lack of "perfect" secure system, not only for login, but for any other component. The only thing to do is to minimize risks by following best practices, but always keeping in mind that total safety doesn't exist, so your question is quite difficult to answer, although there are some good examples out there nothing is perfect, security is a very fast evolving topic.
For me the main things to solve are:
-Data transmission: The user is always going to type a password and this has to be sent to your system before it was processed, so there is a high risk of being intercepted if you are using an open channel. To solve this you MUST use transport the data over an encrypted channel (SSL), no other way unless you drop the common password (for example using one-time use tokens, or delegating the authentication to a third party, like Facebook connect or openId). See "How to Make a Secure Login Form with SSL"
-Input Sanitation: To avoid XSS and SQL Injection consider any input that comes from a client as a potentially risk point, therefore you have to perform validation against anything that comes form outside --> doc. Another good practice is never use the inputs directly on queries, use as bind variables in prepared statements or stored procedures.
-Password Storage: Password should always be stored encrypted with a one way hash algorithm, so even in the case of someone accessing your DB, there is no way to recover the original passwords. Also use techniques as Salting, Hashing multiple times, etc... Also be careful to choose an algorithm that is not weak or outdated (like MD5), which can be broken by brute force easily with the increasing CPU power.
-Infrastructure: Have your machines, OS, frameworks, libraries always updated to avoid bugs and 0 day attack. Any system today is enormously complex, and the system is as secure as it weakest component.
-Other Things to Consider: Review your security policy regularly to see if needs to update anything, implement password policies (expiration, reuse, etc...), log access, use monitoring tools for your systems, etc etc etc
And after all that, you can still be sure that if someone has enough time and resources, your system will fall.
Your question, can't be that agnostic, and must be divided in your two main concerns:
Transmitting passwords in the clear.
Xss, Sql injection.
No system will be declared secured per se, but you can try your best to minimize the risks by using proven concepts.
So let's say you have the chance to design your own "secure system", what do you need?
At minimum you will need a basic set of tools:
Client side data encripting: (Javascript here, i think you will find lots of info of how to send your data in data 64 or something like that, remember you are searching for one way or two way encription)
DB Encription: (One way-two way encription, but never save passwords in the clear)
SQl injection: (mysql_real_escape_string() comes to mind).
Every language has some sort of protection built in, it is when building large projects that sometimes we may forget to sanitize some querys
I repeat no system will ever be declared secure, however you can add some other security measures as in:
access_tokens = timed-strings that allow to validate user login.
captcha_after_few_intents = you should add this definitely.
block_account_after_few_trys = pain in the * for users, but definitely worth it.
login_token = store a token unique for that user, and use it in all GET/POST transactions
SSL
From Bank Security:
Automatic gsm devices that generates RANDS and access_tokens valid only for a short time.
mouse keyboard: evitates keyloggers
random_access_question:
check_random_account_country_change = let's say user is from albany and next day he logs in from south america, that should maybe raise a flag to your system.
I'm sure you will find plenty of advice somewhere, but remember you at end will end talking html, and some js, your main defense is on the server side, so be good, or be good at it.
What are some effective and secure methods of securing SQL queries?
In short I would like to insure that programmers do not see the passwords used by the application to perform queries. Something like RSA or PGP comes to mind, but don't know how one can implement a changing password without being encoded in the application somewhere.
Our environment is a typical Linux/MySQL.
This might be more of a process issue and less of a coding issue.
You need to strictly separate the implementation process and the roll-out process during software development. The configuration files containing the passwords must be filled with the real passwords during roll-out, not before. The programmers can work with the password for the developing environment and the roll-out team changes those passwords once the application is complete. That way the real passwords are never disclosed to the people coding the application.
If you cannot ensure that programmers do not get access to the live system, you need to encrypt the configuration files. The best way to do this depends on the programming language. I am currently working on a Java application that encrypts the .properties files with the appropriate functions from the ESAPI project and I can recommend that. If you are using other languages, you have to find equivalent mechanisms.
Any time you want to change passwords, an administrator generates a new file and encrypts it, before copying the file to the server.
In case you want maximum security and do not want to store the key to decrypt the configuration on your system, an administrator can supply it whenever the system reboots. But this might take things too far, depending on your needs.
If programmers don't have access to the configuration files that contain the login credentials and can't get to them through the debug or JMX interfaces then that should work. Of course that introduces other problems but that would potentially satisfy your requirement. (I am not a Qualified Security Assessor - so check with yours to be sure for PCI compliance.)
I consider myself to be quite a good programmer but I know very little about sever administration. I'm sorry if these questions are noobish but I would really appreciate some advice or links on steps I can take to make this more secure.
I've completed a project for a client that involves storing some very sensitive information, ie personal details of big donors. From a programming perspective it's protected using user authentication.
I don't mind spending some money if it means the info will be more secure, what other steps should I take?
Can the database be encrypted some how so that even if the server is compromised people can't just dump the mysqldb and have everything?
Is it worth purchasing an ssl certificate?
The site is currently hosted on a personal hosting plan with a reasonably trustworthy host. Would a virtual private server be more secure? Are there special hosts I can use that take additional steps to protect info (ie would it be more secure on amazon s3)?
As a side note to the specific question, I would recommend reading some books on computer/programming security. Some good ones are 19 Deadly Sins of Software Security and Writing Solid Code.
You don’t need to encrypt the database itself, just encrypt the data before storing it. (Make sure to use real, cryptographically-secure algorithms instead of making one up yourself.)
Using SSL is definitely an important step if you want to avoid MITM attacks or snooping. A certificate allows you to use SSL without having to take extra steps like installing a self-signed one on each of the client systems (not to mention other benefits like revocation of compromised certs and such).
It depends on just how sensitive the information is and how bad leakage would be. You may want to read some reviews of hosts to get an idea of how good the host is. (If possible, sort the reviews ascending by rating and look at the bad reviews to see if they are objective problems that could apply to you and/or have to do with security, or if they are just incidental or specific issues to that reviewer.) As for the “cloud”, you would kind of be taking a chance since real-world security and privacy of it has yet to be determined. Obviously, if you do go with it, you’ll want a notable, trustworthy host like Amazon or Microsoft since they have benefits like accountability and work constantly and quickly to fix any problems.
HTH
This question already has answers here:
Closed 12 years ago.
Possible Duplicate:
PHP 2-way encryption: I need to store passwords that can be retrieved
I know that the best practice for storing user passwords is to store only an irreversible hash of the password.
However, I am developing an application where I will need to store a user's login information for another web service -- I'll need to periodically log them in and perform some maintenance tasks. Unfortunately, the service doesn't offer authorization tokens so I (very apprehensively) have to store the passwords in a way that I can access their plain-text values. I don't own or control the service to which I am authenticating, and the only method is to 'borrow' a users username and password and authenticate.
I am planning to AES_ENCRYPT the passwords in the DB, which means that if somebody is somehow able to access the DB they won't be able to get the plaintext. However my code will need to have access to the key to unencrypt them, thus if the entire server is compromised this is no protection and the passwords will be revealed.
Aside from the above-described encryption, are there any best practices or steps I can take to do this as safely as possible?
EDIT
I know that whatever I do, ultimately the passwords must be accessible in plaintext and so a compromised server means the passwords will be revealed, but I am wondering what steps I can do to mitigate my risk. E.G. encrypting the DB protects me in the situation where the DB is compromised but not the entire server. Other similar mitigating steps would be much appreciated.
However, I am developing an application where I will need to store a user's login information for another web service -- I'll need to periodically log them in and perform some maintenance tasks.
OK... I read through the answers and the comments, and about all I can say is I hope you have crack legal team. It sounds to me like the service you are offering is predicated on user trust. It's good that it's a user-controlled switch, and not something being helpfully done behind their backs, but I think you want a really iron clad service agreement on this.
That said, there's a lot of security paranoia you can invoke. You'll have to figure out how much you want to go through based on the harm to your product, your company and users if a break in occurs. Here's thoughts:
Data storage - store the passwords far away from where an attacker can get in. Highly access controlled files, a database on a back end machine, etc. Make any attacker have go to through layers of defense just to get to the place the data is stored. Similarly have network protection like firewalls and up to date security patches. No one thing works in isolation here.
Encryption - any encryption technique is a delaying tactic - one the attacker has your data, they will eventually crack your encryption given an infinite amount of time. So mostly you're aiming to slow them down long enough for the rest of the system to discover you've been hacked, alert your users, and give the users time to change passwords or disable accounts. IMO - either symmetric or assymetric cryptography will work - so long as you store the key securely. Being a PKI person myself, I'd lean towards assymmetric crypto just because I understand it better and know of a number of COTS hardware solutions that make it possible to store my private key extremely securely.
Key storage - your encryption is only as good as your key storage. If the key is sitting right next to the encrypted data, then it stands to reason that the attacker doesn't need to break your crypto, they just use the key. HSM (hardware security modules) are the high end choice for key storage - at the upper ranges these are secure boxes that are tamper proof which both hold your keys and perform crypto for you. At the low end, a USB token or Smart Card could perform the same function. A critical part of this is that ultimately, it's best if you make an admin activate key access on server startup. Otherwise, you end up with a chicken and egg scenario as you try to figure out how to securely store the ultimate password.
Intrusion detection - have a good system in place that has a good chance of raising alarms if you should get hacked. If your password data is compromised, you want to get the word to your users well ahead of any threat.
Audit logging - have really good records of who did what on the system - particularly in the vicinity of your passwords. While you could create a pretty awesome system, the threat of privileged users doing something bad (or dumb) is just as bad as external threats. The typical high end auditing systems track high privilege user behavior in a way that can't be viewed or tampered with by the high privilege user - instead, there's a second "auditor" account that deals only with audit logs and nothing else.
This is a highlight of the high points of system security. My general point is - if you are serious about protecting user passwords, you can't afford to just think about the data. Just encrypting the passwords is not likely to be enough to really protect users and safeguard trust.
The standard way to approach this is to consider the cost of explotation vs. the cost of protection. If both costs are too high for the value of the feature, then you have a good indication that you shouldn't bother doing it...
As you said, your code will eventually need the key and so if the server is compromised, so will be the passwords. There is no way around it.
What you can do is have a very minimal proxy whose only job will be to have the passwords, listen to the requests from your main application, connect to the service in question, and return the response to your application. If that very simple proxy is all that is running on a server then it will be much less likely to be compromised than a complicated application running on a server with many services.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
If I had let's say a sensitive report in PDF format and wanted to send it to someone, what is the most secure way?
Does a desktop application make it more secure? Since we are basically doing a client to server communication via private IP address? Then add some kind of standard encryption algorithm to the data as you send it over the wire?
What about a web based solution? In web based, you have a third person in the loop. Sure, it would do the same kind of encryption that I would have on a desktop.. but now instead of client->server directly, you have client->server | server<- client... You also have exposure to the broad internet for any intruders to jump in, making yourself more open to man-in-middle attack... One thing the web has going for it is digitial certificates but I think that is more authentication than authorization.. which the desktop problem doesnt have?
Obviously from a usability point of view - a person wants to just goto a web page and download a report he's expecting. But most secure? Is desktop the answer? Or is it just too hard to do from a usability perspective?
OK there seems to be some confusion. I am a software engineer and am facing a problem where business users have some secure documents that they need to distribute - I am just wondering if using the web and SSL/CA is the standard solution to this, or maybe a desktop application could be the answer??
The method that comes to mind as being very easy (as in it has been done a lot and is proven) is just distributing via a web site that is secured with SSL. It's trivial to set up (doesn't matter if you're running Windows, *nix, etc) and is a familiar pattern to the user.
Setting up a thick client is likely more work because you have to do the encryption yourself (not difficult these days, but there is more to know in terms of following best practices). I don't think that you'll gain much (any?) security from having to maintain a significantly larger set of code.
Most secure would be print it, give it to a courier in a locked briefcase, and have the courier hand deliver it. I think that'd be going overboard, though :)
In real world terms, unless you're talking national security (in which case, see courier option above), or Trade Secrets Which Could Doom Your Company (again, see courier option above), having a well encrypted file downloaded from the web is secure enough. Use PGP encryption (or similar), and I recommend the Encrypt and Sign option, make the original website a secure one as well, and you're probably fine.
The other thing about a desktop application is: how is it getting the report? If it's not generating the report locally, it's really doing just as many steps as a web page: app requests report, report generated, server notifies client, client downloads.
A third option, though, is to use something other than the website to download the reports. For instance, you could allow the user to request the report through the web, but provide a secure FTP (SFTP or FTPS) site or AS2 (or AS3) connection for the actual download.
Using a secure file transfer (or managed file transfer) is definitely the best option for securely transferring electronic data. There are smaller, more personal-use solutions out there like Dropbox or Enterprise solutions like BiscomDeliveryServer.com
Print it off, seal it in an envelope, hire some armed guards for protection and hand deliver it to them.
You may think its a silly answer, but unless you can identify what your threat vectors are any answer is pretty meaningless, since there is no guarantee it will address those threats.
Any system is only as secure as it's weakest link. If you sent the document securely and the user downloaded / saved it to their desktop then you'd be no better off than an unsecure system. Even worse they could get the docuemnt and then send it onto loads of people that shouldn't see it, etc. That leads on to a question whether you have an actual requirement that they can only view and not download the document? If not, why go to all this effort?
But if they are able to down load it, then the most secure method may be to send them an email telling them that the document is available. They then connect to a system (web / ftp?) using credentials sent separately to authenticate their access.
I'm surprised no one has mentioned a PK-encryption over email solution. Everyone in the "enterprise" gets a copy of everyone else's public key and their own private key. Lots of tools exist to do the heavy-lifting. Start with PGP and work from there.