[jira] [Commented] (FILEUPLOAD-119) The encryption & decryption of uploaded file
[ https://issues.apache.org/jira/browse/FILEUPLOAD-119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16477974#comment-16477974 ] David Carboni commented on FILEUPLOAD-119: -- To close this off, I've released at 2.1.0 version of encrypted-file-upload as a companion to FileUpload: * Github: [https://github.com/davidcarboni/encrypted-file-upload] * Maven Central: [https://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22com.github.davidcarboni%22%20AND%20a%3A%22encrypted-file-upload%22] David > The encryption & decryption of uploaded file > > > Key: FILEUPLOAD-119 > URL: https://issues.apache.org/jira/browse/FILEUPLOAD-119 > Project: Commons FileUpload > Issue Type: New Feature > Environment: Windows/Linux >Reporter: inderjeet >Priority: Critical > > Hi, > Can we upload the file in the encypted format and later decrypt it to show > the file so that noone can directly open the file from the disk space (hard > disk) where i have uploaded the file usinf fileUpload functionality. This is > the major concern for our project ? > Is there any external library which can do this for us even just after we > upload the file through this API ? > Thanks & Regards > Inderjeet -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (FILEUPLOAD-119) The encryption & decryption of uploaded file
[ https://issues.apache.org/jira/browse/FILEUPLOAD-119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16475943#comment-16475943 ] David Carboni commented on FILEUPLOAD-119: -- Thanks for the reply Jochen, I respect your view on what should be in or out of the library. I've occasionally had to make calls on what should be in or out of libraries I've built, even when I've had willing contribution offers, (in my case from colleagues I could talk things through with). I believe a clear understanding of intent and scope is key to the integrity of a library and support that. Thanks for the offer to support the ability for an encrypted implementation to work with FileUpload. Having built a range of options (specifically implementing FileItem) the current implementation of FileUpload enables this to be done without breaking the interface. I'll update the release of my original companion library above. Is there a way to offer this as an option for people who do want the additional capability? Thanks David > The encryption & decryption of uploaded file > > > Key: FILEUPLOAD-119 > URL: https://issues.apache.org/jira/browse/FILEUPLOAD-119 > Project: Commons FileUpload > Issue Type: New Feature > Environment: Windows/Linux >Reporter: inderjeet >Priority: Critical > > Hi, > Can we upload the file in the encypted format and later decrypt it to show > the file so that noone can directly open the file from the disk space (hard > disk) where i have uploaded the file usinf fileUpload functionality. This is > the major concern for our project ? > Is there any external library which can do this for us even just after we > upload the file through this API ? > Thanks & Regards > Inderjeet -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (FILEUPLOAD-119) The encryption & decryption of uploaded file
[ https://issues.apache.org/jira/browse/FILEUPLOAD-119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16474046#comment-16474046 ] David Carboni commented on FILEUPLOAD-119: -- Hi Jochen, thanks for the comment. Strictly speaking I agree. The focus of fileupload is parsing multipart uploads. The content being handled is the user's (i.e the server-side application's) responsibility. From this perspective it's clear-cut that encryption is not a FileUpload feature. I've set out my thinking below, based on the progress of encryption on the Web, and on parallels that have emerged since this feature was first raised. I hope this provides a clear, thoughtful picture and I'd welcome your thoughts. This thinking is what prompted me to create an "implicit encryption" implementation, which I used in delivering the public-facing service of a medium-sized UK government organisation dealing in market-moving economic data, where I (understandably) needed to satisfy demanding security constraints. Here's where I think there are areas worth considering: * FileUpload is accepting and processing data "on behalf of" a consuming application and processing uploads internally. Uploads ** might be written to disk, for an indefinite period, and could be accessible to other user accounts on the machine. The caller needs to go to some length to manage this (setting a repository location with appropriate OS permissions, setting a FileCleaningTracker, or explicitly deleting uploads). For the duration that FileUpload accepts and holds data, it would seem there's a "duty of care" towards the caller, especially where the caller may not be fully aware of these settings (and may not have access to the underlying OS). * As a parallel, I'm thinking of AWS EBS or S3. It's not _strictly_ the storage provider's responsibility to encrypt content - users really should encrypt data themselves. However the feature is beneficial and facilitates solutions with reduced security risk that minimise the effort required on the part of the user. Unpacking this thinking, whilst a user "could" implement encryption, there are reasons why a user won't, or shouldn't have to: * What happens behind the FileItem interface, whilst data sit inside the implementation, ideally shouldn't concern the user (or worry their security assurance team). * User convenience (e.g. transparent encryption, as with AWS or https) dramatically reduces friction / barrier to (good) implementation and enables solutions to be more secure "by default". * Creating a Cipher[Input|Output]Stream requires significantly more work than wrapping an existing stream (as with say Buffered[Input|Output]Stream). It requires acquiring an encryption key (of the right type and length), acquiring and initialising a Cipher (of the right algorithm and mode, and introducing a suitable initialisation vector) before the stream class can be instantiated. Using a cipher stream classes means handling half a dozen checked exceptions (NoSuchAlgorithmException, NoSuchPaddingException, InvalidAlgorithmParameterException, InvalidKeyException, IllegalBlockSizeException, BadPaddingException). This makes for heavy-going code to handle a file upload. * Most developers know implementing an encryption algorithm is unacceptable, but even correct use of encryption primitives from a trusted library is non-trivial (and using JCE adds complication on top of this). The variety of primitives, algorithms, modes, key lengths, right down to the need for key management and secure random number generation, means "good" encryption remains hard for most - and few will be allowed the time to get it right (in my case I got lucky!). * Encryption that doesn't require user action (or behaviour change) and uses ephemeral keys (so avoiding key management) provides a very low barrier to use. The Web has come a long way since 2006 and encryption is now the norm online (I'm thinking of advances like Letsencrypt, Chrome frowning on non-https sites, and increased business awareness data breaches). I've had to deal with an enterprise security team who weren't happy to accept data not encrypted at rest, even where underlying storage was encrypted, because they weren't happy to accept the risk of administrative accounts on the machine. I hope this is constructive and would be interested to hear what you think. > The encryption & decryption of uploaded file > > > Key: FILEUPLOAD-119 > URL: https://issues.apache.org/jira/browse/FILEUPLOAD-119 > Project: Commons FileUpload > Issue Type: New Feature > Environment: Windows/Linux >Reporter: inderjeet >Priority: Critical > > Hi, > Can we upload the file in the encypted format and later decrypt it to show > the file so that noone can directly open
[jira] [Commented] (FILEUPLOAD-119) The encryption & decryption of uploaded file
[
https://issues.apache.org/jira/browse/FILEUPLOAD-119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16473157#comment-16473157
]
David Carboni commented on FILEUPLOAD-119:
--
Hi there,
Appreciate I'm late to this party, but, for the benefit of Googlers and as an
offer to the maintainers if helpful, this is something I have implemented,
using a few different options.
In terms of core FileUpload functionality, it would seem useful feature
(security risk reduction) to provide "transparent encryption" so that no data
are ever written to disk in the clear - encryption at rest.
If, at the same time, users do not need to take any action to benefit from
encryption and encryption does not affect their implementation, this would be
ideal (like https, it "just happens").
I've been using the JCE for encryption for some time
([https://github.com/davidcarboni/cryptolite-java]) so I've worked out four
approaches to providing encryption, all of which respect the FileItem interface.
1. As a *stand-alone library*
([https://github.com/davidcarboni/encrypted-file-upload]):
{code:java}
com.github.davidcarboni
encrypted-file-upload
1.0.2
{code}
2-4. As a fork of Commons Fileupload with different approaches on different
branches ([https://github.com/davidcarboni/commons-fileupload]):
* *Implement FileItem*, using a copy of DiskFileItem as a starting point
(branch: _encrypted-file-item-implementation branch_)
* *Extend DiskFileItem* to modify writes and reads (branch:
_encrypted-file-item-extends_)
* *Modify DiskFileItem* itself. In this case I needed to reduce the visibility
of getStoreLocation() (which is not part of the FileItem API) because the
returned file is encrypted and therefore meaningless (_branch:
encrypted-file-item-default_)
All of these allow you to use a [corresponding] FileItemFactory. Modifying
FileItem itself has the advantage that encryption becomes the default, however
users of the DiskFileItem method getStoreLocation will be affected because
there's no way to recover the key used to encrypt data written to disk.
It's an API-neutral change with respect to FileItem and, based on the unit
tests, does not affect the behaviour of DiskFileItem.
Many thanks
David
> The encryption & decryption of uploaded file
>
>
> Key: FILEUPLOAD-119
> URL: https://issues.apache.org/jira/browse/FILEUPLOAD-119
> Project: Commons FileUpload
> Issue Type: New Feature
> Environment: Windows/Linux
>Reporter: inderjeet
>Priority: Critical
>
> Hi,
> Can we upload the file in the encypted format and later decrypt it to show
> the file so that noone can directly open the file from the disk space (hard
> disk) where i have uploaded the file usinf fileUpload functionality. This is
> the major concern for our project ?
> Is there any external library which can do this for us even just after we
> upload the file through this API ?
> Thanks & Regards
> Inderjeet
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
