Recent

Author Topic: Remote application  (Read 764 times)

kupferstecher

  • Sr. Member
  • ****
  • Posts: 431
Remote application
« on: April 23, 2021, 11:46:11 am »
Hello,

I'm thinking about a server application, where multiple clients can connect to control a device and to show and visualize data. User identification (Password Login) is also needed and basic encryption.
Browser applications and the like could be a choice, but I prefere the native look and feel of a desktop application, so Lazarus it shall be.

My idea was to implement a custom protokoll based on TCP. Specifically I would define frames/packages, that start with a start character (e.g. ">"), followed by the frame length, followed by the frame data and finally terminated by a stop character (e.g. "<"). A frame would start with a command-ID and the following content would be command specific. Encryption could be done on frame level.
I also thought about using HTTP-requests instead, an advantage would be that each request has a response, so the client gets an answer in context. The problem that I see by that, is that the line is blocked until the response is delivered, which slows down things especially if small data packets are transfered in each request. As I understand browsers open several connections to circumvent this problem. If I try to implement that as well, it seems not very easy on client side: dynamically establish connections, route the responses to handlers etc.
On the other hand for the "single connection solution", responses would just be queued out and thus couldn't be associated to a request. For a simple OK, the client wouldn't know, which request was OK'ed by that, so additional information would have to be added on sender side and decoded/routed on receiver side. Which seems not very well scaling.


Has someone here done something like that before?
Some advice?

Thanks~

MarkMLl

  • Hero Member
  • *****
  • Posts: 2477
Re: Remote application
« Reply #1 on: April 23, 2021, 12:53:26 pm »
I am sure that there will be plenty of people who will tell you that you should be using something HTTP-based. I'm not happy saying anything about that either way, but will make two comments:

* It might be worth exploring whether a VNC server could be embedded in an application, to serve the main form/window to a remote client (and using MDI rather than multiple windows where necessary).

* There's a whole lot of details relating to remote control/reporting that have previously been worked out using Telnet, another obvious possibility is SSH. These have the advantage that in extremis you can use standard client software, but if you decide to go that way don't use LNet's Telnet server: there's bugs in it that I've never worked out how to expunge, and you'd be better writing your own server framework using threads.

MarkMLl


Turbo Pascal v1 on CCP/M-86, multitasking with LAN and graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

Thaddy

  • Hero Member
  • *****
  • Posts: 10778
Re: Remote application
« Reply #2 on: April 23, 2021, 01:10:05 pm »
1. Basic encryption is not enough. You should use solid encryption, TLS 1.2. upwards.
2. Not http, but https...
3. You will need certificates
4. You will also need strong password verification( Or properly distributed certificates)
5. Never store passwords, store secure hashes,
6. Password recovery (actually: change) should be done with 2 factor authentication

That's about all you have to do, apart from a properly configured server, which is not about programming.

This is not overdone, it is a basic minimum.
On the server side, make sure you have protection by something like Fail2ban and make sure individual (sub-) servers are protected by certificates too. Overhead is likely minimal.
« Last Edit: April 23, 2021, 01:17:43 pm by Thaddy »

kupferstecher

  • Sr. Member
  • ****
  • Posts: 431
Re: Remote application
« Reply #3 on: April 23, 2021, 01:39:09 pm »
Thanks for the replys.

VNC server
 [...]
Telnet
I will have a closer look!

Basic encryption is not enough. [...]
This is not overdone, it is a basic minimum.
Perhaps I have to clarify, the intended use is within a private network, if it goes over the internet it will be tunneled by VPN. Encryption in some extend I still see necessary, as passwords are to be transferred (wheater hashed or not).

Thaddy

  • Hero Member
  • *****
  • Posts: 10778
Re: Remote application
« Reply #4 on: April 23, 2021, 01:58:20 pm »
as passwords are to be transferred (wheater hashed or not).
That should not be the case and is really bad programming: the password needs to be hashed client-side.
A password should NEVER reach the line. Period.

I am a bit bemused that such an experienced programmer would suggest such a basic mistake.
« Last Edit: April 23, 2021, 02:02:57 pm by Thaddy »

kupferstecher

  • Sr. Member
  • ****
  • Posts: 431
Re: Remote application
« Reply #5 on: April 23, 2021, 02:02:40 pm »
I mean even if it is hashed, it should be transfered encrypted.

Thaddy

  • Hero Member
  • *****
  • Posts: 10778
Re: Remote application
« Reply #6 on: April 23, 2021, 02:04:01 pm »
I mean even if it is hashed, it should be transfered encrypted.
If using a secure hash, it does not matter. It is (should be) a one way hash.

MarkMLl

  • Hero Member
  • *****
  • Posts: 2477
Re: Remote application
« Reply #7 on: April 23, 2021, 07:12:23 pm »
as passwords are to be transferred (wheater hashed or not).
That should not be the case and is really bad programming: the password needs to be hashed client-side.
A password should NEVER reach the line. Period.

I am a bit bemused that such an experienced programmer would suggest such a basic mistake.

I'm not saying this is justifiable, or acceptable practice, but there is one common exception here.

If a password is being sent to some sort of wallet, even a local one, it can't be hashed since it needs to be retrieved "in clear" in order to be passed to some other program or service.

So the ideal would be that a password was put into a local string, hashed, and then the string overwritten before being freed (since FPC does not do this). The less-than-ideal is that a password is sometimes sent over some sort of interprocess communication, or USB, or a network connection, to a storage device, and is similarly retrieved. In those cases the more encryption that can be used the better.

MarkMLl
Turbo Pascal v1 on CCP/M-86, multitasking with LAN and graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

Thaddy

  • Hero Member
  • *****
  • Posts: 10778
Re: Remote application
« Reply #8 on: April 23, 2021, 08:08:37 pm »
No. Only the hash warrants verification. That's plain stupid Mark.
Do not make such remarks in plain view ever again.

MarkMLl

  • Hero Member
  • *****
  • Posts: 2477
Re: Remote application
« Reply #9 on: April 23, 2021, 08:38:04 pm »
No. Only the hash warrants verification. That's plain stupid Mark.
Do not make such remarks in plain view ever again.

It's the truth. I'm not condoning it, but how do you think that the various password vaults (e.g. as USB sticks) or Firefox's "save password" facility works? In fact while the latter is extremely convenient there's programs which can read and extract the user ID and password for backup purposes.

MarkMLl
Turbo Pascal v1 on CCP/M-86, multitasking with LAN and graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

Thaddy

  • Hero Member
  • *****
  • Posts: 10778
Re: Remote application
« Reply #10 on: April 23, 2021, 10:28:08 pm »
Well, Mark,

If I was to write code that would send a password instead of just the hash over a wire, I would fire myself... You can not find any excuse for that,  %) O:-)

MarkMLl

  • Hero Member
  • *****
  • Posts: 2477
Re: Remote application
« Reply #11 on: April 23, 2021, 10:58:57 pm »
Well, Mark,

If I was to write code that would send a password instead of just the hash over a wire, I would fire myself... You can not find any excuse for that,  %) O:-)

No doubt... but plenty of things do.

Again: I am NOT saying it's a good idea, but it's a fact of life. It would obviously be preferable if there were a universally-agreed one-way function that was *always* used to hash passwords so that they are *never* moved out of the original program in clear, but that quite simply doesn't exist.

What's more, while a password management program could obviously always hash a password and send that to the remote program when an account was being set up (BTDT), it would then be impossible for the user to enter the password manually if he needed to.

So for the foreseeable future, we're stuck with passwords being sent over HTTPS, and (more worryingly) being moved around locally via pipes, sockets or buses- any of which could be tapped. And quite frankly, since FPC will release string storage without wiping it I don't think we're in a good position to complain about that.

MarkMLl
Turbo Pascal v1 on CCP/M-86, multitasking with LAN and graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

zamronypj

  • Full Member
  • ***
  • Posts: 116
    • Fano Framework, Free Pascal web application framework
Re: Remote application
« Reply #12 on: April 24, 2021, 12:40:36 am »
That should not be the case and is really bad programming: the password needs to be hashed client-side.
A password should NEVER reach the line. Period.
Are you joking?
On contrary, clear password is sent over the wire and then server calculates password hash from clear password then compares it with password hash that server stores in their storage. To protect clear password in transit from man in middle attack, you need to encrypt network traffic, that is , for example what https protocol is for.

If password hash is hashed on client side and password hash is sent over the wire, client side needs to know to build hash. Password hash become actual password in server as server will not know how to verify it and just compare it as is.

password hash on client-side only make sense of you do not trust server (because server may compromise your data or operated insecurely). If you do not trust the server then you should not trust anything come from server, for example if server sends JavaScript code that calculate password hash then you should not trust it because it may be compromised code from attacker.

Good point of using password hash on client-side is, for me,  to reduce server load as password hash is computationally expensive.
« Last Edit: April 24, 2021, 02:04:16 am by zamronypj »
Fano Framework, Free Pascal web application framework https://fanoframework.github.io
Personal Projects https://v3.juhara.com
Github https://github.com/zamronypj

PierceNg

  • Full Member
  • ***
  • Posts: 103
Re: Remote application
« Reply #13 on: April 24, 2021, 05:14:56 am »
That should not be the case and is really bad programming: the password needs to be hashed client-side.
A password should NEVER reach the line. Period.
Are you joking?
On contrary, clear password is sent over the wire and then server calculates password hash from clear password then compares it with password hash that server stores in their storage. To protect clear password in transit from man in middle attack, you need to encrypt network traffic, that is , for example what https protocol is for.

If password hash is hashed on client side and password hash is sent over the wire, client side needs to know to build hash. Password hash become actual password in server as server will not know how to verify it and just compare it as is.

+1

This is correct.

MarkMLl

  • Hero Member
  • *****
  • Posts: 2477
Re: Remote application
« Reply #14 on: April 24, 2021, 09:25:23 am »
password hash on client-side only make sense of you do not trust server (because server may compromise your data or operated insecurely). If you do not trust the server then you should not trust anything come from server, for example if server sends JavaScript code that calculate password hash then you should not trust it because it may be compromised code from attacker.

Ideally, the server shouldn't be trusted: the possibility of finding bulk passwords "in clear" makes servers "low-hanging fruit" as far as hackers are concerned.

In reality though we have to rely on HTTPS (or SSH for text sessions), and on mandatory standards for server operators if they want to interact with credit cards etc... which is why the conduct of companies like TalkTalk (who tried to conceal that they'd been hacked) and their principal Dido "Queen of Carnage" Harding has been so widely criticised.

My apologies to OP, this subthread risks obscuring his question.

MarkMLl
Turbo Pascal v1 on CCP/M-86, multitasking with LAN and graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

 

TinyPortal © 2005-2018