wishlist: _simple_ file transfer and keylogger protection

[GoogleCodeExporter]

A couple of features I would _really_ like to see in shellinabox

- an integral _basic_ file transfer facility (simple send and receive via
HTTP/HTTPS, anything more would clutter the system design)

- a on-screen keyboard support to defeat keyloggers when typing
passwords (e.g. by means of a imagemap with the server side app to convert 
click on a region to a keypress): after all, it's meant to be used on public 
boxes... I am currently using the pam_otpsms module, but it's quite more 
awkward.

That said, it's a really cute software and I'd like to thank its
authors for making it freely available

Regards
Federico Bianchi

Original issue reported on code.google.com by effeb...@gmail.com on 24 Aug 2010 at 3:58

[GoogleCodeExporter]

The file transfer feature has been requested a couple of times. I haven't quite 
figured out yet, how I would want to implement this. But I can understand the 
usefulness. I'll probably eventually think of something.

I believe the usefulness of an on-screen keyboard might be limited. From what I 
have been told about key loggers, they are quite sophisticated these days and 
include screenshot ability. So, not sure anything I could do would help all 
that much.

An out-of-band authentication mechanism is really the best protection against 
keyloggers. If you have the ability to use some form of OTP token, then I would 
strongly advise to stick with that.

Original comment by zod...@gmail.com on 24 Aug 2010 at 4:09

• Changed state: Accepted

[GoogleCodeExporter]

Last, first:

- keyloggers may be _very_ sophisticated, but in this case we talk about 
tracking mouse clicks while getting the screen. It can be done, but this raises 
the bar quite a lot, much more than any "standard" (non-OTP) passphrase 
authentication

- as of file transfer, I actually thought of terminal emulation days, where 
fetching a file from the host usually involved typing a command on the server 
(e.g., "sib_send foo bar" triggering a new browser window asking to download of 
"bar") and receive was client-initiated, running the proper command 
automatically. Nothing very sophisticated, as you may see

Original comment by effeb...@gmail.com on 25 Aug 2010 at 6:11

[GoogleCodeExporter]

I don't need personnally a virtual keyboard, but if you have to implement it, 
remember to use a keyboard that simulate keypress on hover after x seconds (2 
seems to be a good value), instead of clicking. Thus, the keylogger have to 
take a video instead of screenshot at each mouse click event. And it seems damn 
painful to track this.
Obviously, it's also painful to enter the password, since it can take a lot of 
times…

Original comment by ZeGlan...@gmail.com on 27 Aug 2010 at 9:47

[GoogleCodeExporter]

I added a first version of an on-screen keyboard. It probably still needs a few 
tweaks, but for now it should get you started.

Original comment by zod...@gmail.com on 4 Sep 2010 at 5:56

[GoogleCodeExporter]

It's exactly on the lines of what I had in mind; I tried it a couple of days 
ago and... it works.

That said, I found a cute paper focusing on OTP -> traditional password bridges 
without ever storing the password itself. See 
http://research.microsoft.com/en-us/um/people/cormac/URRSA/URRSA_usage.htm for 
details.

Unfortunately, the implementation itself is not accessible outside corpnet, but 
the idea looks very promising.

Original comment by effeb...@gmail.com on 12 Sep 2010 at 2:31

[GoogleCodeExporter]

Take a look at http://code.google.com/p/google-authenticator/ for an tOTP 
implementation that runs on several popular cell phones, and that can be used 
with ShellInABox.

Original comment by zod...@gmail.com on 20 Sep 2010 at 7:04

[GoogleCodeExporter]

What about using the Zmodem protocol for file transfer?  I use Konsole on my 
Linux desktop as a terminal app, and if I connect to a remote BBS, Zmodem works 
flawlessly!  Konsole can detect the special Zmodem signal and starts the file 
transfer.

Original comment by kveron...@gmail.com on 30 Jan 2014 at 8:11

[GoogleCodeExporter]

I was also thinking of zmodem.  The problem is that http file uploads don't use 
zmodem.  You'd need to rewrite the protocol in javascript (not too hard to do 
if someone knows javascript really well).  The back-end server listening on 
port 4200 could detect the zmodem init string and type "rz" for you into the 
shell (and just hope you are running a shell).  The reverse could be done too - 
you type sz at the shell and the javascript end could detect it and start the 
recieve.  HTML5 actually has a file access API.

The only other way I can think of to do it would require that you set up paths 
on the server where the files would be transfered and such.  The zmodem way may 
be old school, but I think its reasonable in this case.

Original comment by uudrui...@gmail.com on 13 Nov 2014 at 7:14

[GoogleCodeExporter]

on filetransfer: how about this one?

a, sending out file should be simple command should be a simple command (packed 
with shellinabox)
and called like: shellinaboxsend a.txt
this way it could track down the process tree, if it has a shellinaboxd process 
as "parent" :) and once it is, pipe the outgoing file into that process, and 
then shellinaboxd on client side opens a new tab in the browser with the 
downloadable file

b, receiving files should work similar, you invoke a command in a box, like 
"shellinaboxrecv" listening for incomings, and until it's running ("logged in 
into parent process"), the user can access "send file" menuitem from context, 
once it's started to upload, shellinaboxrecv saves the received files to the 
directory given, or the current working directory if parameter is omitted :)

Original comment by lorenzo....@gmail.com on 23 Feb 2015 at 7:00