<p>Website: <a href="https://www.nafue.com">nafue.com</a></p>
<p>Hey guys, this is still a work in progress but I'd love to have your feedback. Feel free to take a look at the code and verify it's secure (<a href="https://github.com/menkveldj/nafue">https://github.com/menkveldj/nafue</a>). </p>
<p>User can share a file that is encrypted client side using a password to generate a Pbkdf2 key to AES 256 encrypt the data before uploading it to s3. The user receives a link to share. The link can only be accessed once. After first time access or 24 hours the link and encrypted file are deleted. The receiver must enter the same password to decrypt and recover the file. <strong>No one but the sharer and receiver know what the actual file is.</strong></p>
<p>Upload:</p>
<ul>
<li>Choose a file to share</li>
<li>Choose a complex password to create a Pbkdf2 key with</li>
<li>AES 256 Encrypt File, file name, file type</li>
<li>Generate 1 time link and s3 pre-signed upload request</li>
<li>Upload encrypted blob to s3</li>
<li>Provide 1 time link to access file</li>
</ul>
<p>Download:</p>
<ul>
<li>Navigate to onetime link</li>
<li>Generate s3 pre-signed download; delete onetime link</li>
<li>Download file</li>
<li>Ask for password (same as used to encrypt)</li>
<li>Decrypt file</li>
<li>Provide download prompt</li>
</ul>
<p>Still In Progress:</p>
<ul>
<li>Add job to delete links after 24 hours; don’t just rely on check when link is requested</li>
<li>Add job to delete files after 24 hours; don’t just rely on check when link is requested</li>
<li>Add “how it works” page</li>
<li>Add “progress page”; currently “mobile” </li>
<li>Add Github link to Master</li>
</ul>
<p>Future:</p>
<ul>
<li>iOS App</li>
<li>Android App</li>
<li>Windows App</li>
<li><p>OSX App</p></li>
<li><p>Apps enable larger than 50mb uploads</p></li>
</ul>
<hr/>**评论：**<br/><br/>FUZxxl: <pre><p>So it doesn't actually work yet? Who guarantees us that you actually remove the file from your server? Why should I trust you?</p></pre>menkveldj: <pre><p>It does work. Feel free to try it out!
The code is available in the github link. feel free to audit it and provide feedback. Transparency === ultimate trust.</p></pre>FUZxxl: <pre><p>Sorry, that's not how it works. I just tried the application and I really hate the fact that I have to enter a plain text password into your web form. That essentially means that I have to trust you to not store the unencrypted file or the password. I have to trust the transport channel to not sniff the unencrypted file. I have to trust you to actually run the software you claim to run. Also it seems like you are not salting passwords so standard rainbow table attacks are trivially possible against the encrypted files. That's not at all how security works.</p></pre>menkveldj: <pre><p>Thanks for the feedback. The plain text is required as there is no other way for you to enter a password via an input field. Anything entered client side is going to be "plain" That being said if you take a look in the code the password is salted, and iv's are created. The encryption key is a Pbkdf2 based on the password and salt.</p>
<p>Open up your networks tab and take a look at the data transaction between the webservices and your machine. The only thing transferred is the iv, salt, and encrypted data. You don't have to trust I'm running said client side code. You can see it (app.mini.js)! All the hashing and encryption happens client side in javascript... yes you do have to trust that the server side is running what i say it is, but ultimately after you have verified the only data I'm getting is encrypted or the iv and salt there isn't much to argue about. Yes the iv and salt are helpful for rainbow table, however, they have to be stored somewhere. Where would you like it? Amazon S3 appended to the file or in a DB? Does it matter?</p>
<p>Seriously thanks for the feedback. I appreciate your concerns. Please continue to help by providing suggested answers to your criticisms so this can be improved instead of just critisized.</p>
<p>Finally everything is done over https so there is no sniffing unless your talking Man in the middle.</p>
<p>Ultimately lets be honest nothing is every perfect. The titanic did sync. But I think it's worth making secure file sharing available to the masses. This is my first attempt... lets improve it together!</p></pre>FUZxxl: <pre><p>Well okay. I didn't look that closely. I might have missed this stuff.</p>
<blockquote>
<p>Ultimately lets be honest nothing is every perfect. The titanic did sync. But I think it's worth making secure file sharing available to the masses. This is my first attempt... lets improve it together!</p>
</blockquote>
<p>Good luck with your project. Make sure you have a strategy to deal with law enforcement seizing hard disks from your premises because someone shared child porn.</p></pre>menkveldj: <pre><p>Very good point. I'm hoping (need to look into it) that if you are only transferring encrypted data to me and I have no idea what it is that there isn't much that can be done. I mean... they could take the drives but it's all 100% encrypted before I get it or serve it. How can anyone tell other than the sender and receiver? Not to mention there is no records of it seeings as it's deleted upon download or after 24h. Its probably more likely that they force me to shut down due to "National Security". Hopefully with it being opensourced it's not worth shutting me down as there are 1M other people who could spin it right back up. Thoughts?</p></pre>FUZxxl: <pre><p>Have a back up strategy and make sure that supposedly deleted files are actually gone for good.</p></pre>ChristophBerger: <pre><blockquote>
<p>You don't have to trust I'm running said client side code. You can see it (app.mini.js)! </p>
</blockquote>
<p>How can I be sure that no one tampered with app.mini.js on your server?</p></pre>menkveldj: <pre><p>You could audit it then run a diff on it each time you want to use the site. If you have suggestions that would be easier for the average user please feel free to share :-)</p></pre>twelph: <pre><p>One thing I've seen done is to create a browser plugin and host it on github so that advanced users can verify that the plugin is accurately matching the code on the website to the github repo. </p></pre>menkveldj: <pre><p>not a bad idea</p></pre>ipsq: <pre><p>You've essentially created a worse mega?</p></pre>
