Recent

Author Topic: Remote application  (Read 1379 times)

yus

  • New Member
  • *
  • Posts: 47
Re: Remote application
« Reply #15 on: April 24, 2021, 10:11:33 am »
Everything has already been invented before us  :) Use OAuth authorization from Google Facebook etc.

MarkMLl

  • Hero Member
  • *****
  • Posts: 2875
Re: Remote application
« Reply #16 on: April 24, 2021, 10:19:52 am »
Everything has already been invented before us  :) Use OAuth authorization from Google Facebook etc.

Thus telling Google, Facebook et al. who else you're talking to... which is information they can monetize.

Quite frankly, I'd be happier having the Vatican manage my security. After all they supposedly have the keys of Heaven...

With ongoing apologies to OP.

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

kupferstecher

  • Sr. Member
  • ****
  • Posts: 446
Re: Remote application
« Reply #17 on: April 24, 2021, 11:12:08 am »
My apologies to OP, this subthread risks obscuring his question.
When starting the topic I actually thought about not mentioning encryption as it easily tracks away a discussion. But to discuss a concept such details are important to be factored in. So it had to be :-)

-> I still hope to get more input on the original question. Advantages and Disanvantages of different protocolls and setups.


Password hash become actual password in server as server will not know how to verify it and just compare it as is.
That was my thought as well, if the hash is always the same, then an attacker could just send the recorded hash to gain access. If the hash is based on some kind of key that the server dynamically provides, that - to me - more sounds like encryption. But I never had much to do with these topics.

So discussions/suggestions regarding this topic are welcome as well.

MarkMLl

  • Hero Member
  • *****
  • Posts: 2875
Re: Remote application
« Reply #18 on: April 24, 2021, 11:27:58 am »
Password hash become actual password in server as server will not know how to verify it and just compare it as is.
That was my thought as well, if the hash is always the same, then an attacker could just send the recorded hash to gain access. If the hash is based on some kind of key that the server dynamically provides, that - to me - more sounds like encryption. But I never had much to do with these topics.

Yes, like CHAP but with (by mutual agreement) the password's hash stored at both ends rather than the password itself.

That also means that the plaintext password could be entered into a client on a different system, provided that it was unsalted.

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