Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c++ > #69492 > unrolled thread
| Started by | woodbrian77@gmail.com |
|---|---|
| First post | 2019-10-30 09:58 -0700 |
| Last post | 2020-08-04 18:28 -0700 |
| Articles | 20 on this page of 87 — 17 participants |
Back to article view | Back to comp.lang.c++
Regal eagle / American cloud woodbrian77@gmail.com - 2019-10-30 09:58 -0700
Re: Regal eagle / American cloud Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2019-10-30 18:16 +0000
Re: Regal eagle / American cloud Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2019-10-30 18:27 +0000
Re: Regal eagle / American cloud Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2019-10-30 22:13 +0000
Re: Regal eagle / American cloud woodbrian77@gmail.com - 2019-10-30 22:36 -0700
Re: Regal eagle / American cloud Ian Collins <ian-news@hotmail.com> - 2019-10-31 20:35 +1300
Re: Regal eagle / American cloud woodbrian77@gmail.com - 2019-10-31 10:28 -0700
Re: Regal eagle / American cloud Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-01 08:24 +0100
Re: Regal eagle / American cloud Real Troll <Real.Troll@Trolls.com> - 2019-11-01 17:20 -0400
Re: Regal eagle / American cloud Ian Collins <ian-news@hotmail.com> - 2019-11-02 12:43 +1300
Re: Regal eagle / American cloud Daniel <danielaparker@gmail.com> - 2019-11-01 17:47 -0700
Re: Regal eagle / American cloud woodbrian77@gmail.com - 2019-11-01 19:07 -0700
Re: Regal eagle / American cloud Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2019-11-02 16:33 +0000
Re: Regal eagle / American cloud woodbrian77@gmail.com - 2019-11-02 10:46 -0700
Re: Regal eagle / American cloud Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-02 10:21 +0100
Re: Regal eagle / American cloud woodbrian77@gmail.com - 2019-11-02 10:26 -0700
Re: Regal eagle / American cloud Melzzzzz <Melzzzzz@zzzzz.com> - 2019-11-02 17:43 +0000
Re: Regal eagle / American cloud Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-02 18:52 +0100
Re: Regal eagle / American cloud woodbrian77@gmail.com - 2019-11-02 11:11 -0700
Re: Regal eagle / American cloud David Brown <david.brown@hesbynett.no> - 2019-11-02 20:16 +0100
Re: Regal eagle / American cloud Real Troll <Real.Troll@Trolls.com> - 2019-11-02 16:59 -0400
Re: Regal eagle / American cloud Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2019-11-02 21:23 +0000
Re: Regal eagle / American cloud woodbrian77@gmail.com - 2019-11-02 17:49 -0700
Re: Regal eagle / American cloud woodbrian77@gmail.com - 2019-11-02 17:14 -0700
Re: Regal eagle / American cloud Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2019-11-03 01:15 +0000
Re: Regal eagle / American cloud woodbrian77@gmail.com - 2019-11-02 19:01 -0700
Re: Regal eagle / American cloud Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2019-11-03 03:51 +0000
Re: Regal eagle / American cloud Brian Wood <woodbrian77@gmail.com> - 2021-03-09 20:24 -0800
Re: Regal eagle / American cloud David Brown <david.brown@hesbynett.no> - 2019-11-03 11:35 +0100
Re: Regal eagle / American cloud woodbrian77@gmail.com - 2019-11-03 20:04 -0800
Re: Regal eagle / American cloud Christian Gollwitzer <auriocus@gmx.de> - 2019-11-04 08:07 +0100
Re: Regal eagle / American cloud David Brown <david.brown@hesbynett.no> - 2019-11-04 09:08 +0100
Re: Regal eagle / American cloud woodbrian77@gmail.com - 2019-11-07 08:17 -0800
Re: Regal eagle / American cloud Jorgen Grahn <grahn+nntp@snipabacken.se> - 2019-11-07 16:52 +0000
Re: Regal eagle / American cloud woodbrian77@gmail.com - 2019-11-07 10:54 -0800
Re: Regal eagle / American cloud Jorgen Grahn <grahn+nntp@snipabacken.se> - 2019-11-07 21:33 +0000
Re: Regal eagle / American cloud woodbrian77@gmail.com - 2019-11-09 16:28 -0800
Re: Regal eagle / American cloud woodbrian77@gmail.com - 2019-11-11 22:33 -0800
Re: Regal eagle / American cloud woodbrian77@gmail.com - 2019-11-12 08:26 -0800
Re: Regal eagle / American cloud Keith Thompson <kst-u@mib.org> - 2019-11-12 15:54 -0800
Re: Regal eagle / American cloud woodbrian77@gmail.com - 2020-01-31 21:59 -0800
Re: Regal eagle / American cloud Brian Wood <woodbrian77@gmail.com> - 2020-12-03 09:40 -0800
Re: Regal eagle / American cloud Brian Wood <woodbrian77@gmail.com> - 2020-12-03 09:40 -0800
Re: Regal eagle / American cloud Brian Wood <woodbrian77@gmail.com> - 2021-01-18 20:48 -0800
Re: Regal eagle / American cloud Keith Thompson <kst-u@mib.org> - 2019-11-04 01:00 -0800
Re: Regal eagle / American cloud Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-03 05:20 +0100
Re: Regal eagle / American cloud David Brown <david.brown@hesbynett.no> - 2019-11-03 11:12 +0100
Re: Regal eagle / American cloud "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-11-04 00:30 -0800
Re: Regal eagle / American cloud David Brown <david.brown@hesbynett.no> - 2019-11-04 11:03 +0100
Re: Regal eagle / American cloud "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-11-11 23:38 -0800
Re: Regal eagle / American cloud "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-11-11 23:39 -0800
Re: Regal eagle / American cloud "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-11-02 13:18 -0700
Re: Regal eagle / American cloud Melzzzzz <Melzzzzz@zzzzz.com> - 2019-11-02 20:37 +0000
Re: Regal eagle / American cloud woodbrian77@gmail.com - 2020-02-08 19:54 -0800
Re: Regal eagle / American cloud Ian Collins <ian-news@hotmail.com> - 2020-02-09 19:52 +1300
Re: Regal eagle / American cloud "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2020-02-09 12:54 -0800
Re: Regal eagle / American cloud woodbrian77@gmail.com - 2020-02-27 20:19 -0800
Re: Regal eagle / American cloud Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2020-02-28 16:50 +0000
Re: Regal eagle / American cloud "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2020-02-28 15:34 -0800
Re: Regal eagle / American cloud "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2020-02-28 15:37 -0800
Re: Regal eagle / American cloud woodbrian77@gmail.com - 2020-02-28 16:24 -0800
Re: Regal eagle / American cloud Melzzzzz <Melzzzzz@zzzzz.com> - 2020-02-29 03:48 +0000
Re: Regal eagle / American cloud "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2020-02-28 21:33 -0800
Re: Regal eagle / American cloud Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2020-02-29 06:28 +0000
Re: Regal eagle / American cloud "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2020-02-28 22:34 -0800
Re: Regal eagle / American cloud Melzzzzz <Melzzzzz@zzzzz.com> - 2020-02-29 06:51 +0000
Re: Regal eagle / American cloud Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2020-02-29 07:34 +0000
Re: Regal eagle / American cloud "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2020-02-28 23:40 -0800
Re: Regal eagle / American cloud David Brown <david.brown@hesbynett.no> - 2020-03-01 14:46 +0100
Re: Regal eagle / American cloud "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2020-03-01 12:59 -0800
Re: Regal eagle / American cloud David Brown <david.brown@hesbynett.no> - 2020-03-01 22:47 +0100
Re: Regal eagle / American cloud red floyd <no.spam@its.invalid> - 2020-03-01 22:14 -0800
Re: Regal eagle / American cloud woodbrian77@gmail.com - 2020-03-03 08:06 -0800
Re: Regal eagle / American cloud "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2020-03-02 13:21 -0800
Re: Regal eagle / American cloud "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2020-03-02 13:24 -0800
Re: Regal eagle / American cloud David Brown <david.brown@hesbynett.no> - 2020-03-03 08:11 +0100
Re: Regal eagle / American cloud "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2020-03-03 01:31 -0800
Re: Regal eagle / American cloud "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2020-03-03 01:33 -0800
exception with distinct data members and concatenated what "daniel...@gmail.com" <danielaparker@gmail.com> - 2020-12-08 08:24 -0800
Re: exception with distinct data members and concatenated what Öö Tiib <ootiib@hot.ee> - 2020-12-08 10:26 -0800
Re: exception with distinct data members and concatenated what "daniel...@gmail.com" <danielaparker@gmail.com> - 2020-12-08 11:00 -0800
Re: exception with distinct data members and concatenated what Öö Tiib <ootiib@hot.ee> - 2020-12-08 13:17 -0800
Re: exception with distinct data members and concatenated what Paavo Helde <myfirstname@osa.pri.ee> - 2020-12-08 22:13 +0200
Re: Regal eagle / American cloud "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2020-02-28 23:38 -0800
Re: Regal eagle / American cloud Melzzzzz <Melzzzzz@zzzzz.com> - 2020-02-29 06:50 +0000
Re: Regal eagle / American cloud "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2020-02-28 23:32 -0800
Re: Regal eagle / American cloud woodbrian77@gmail.com - 2020-08-04 18:28 -0700
Page 4 of 5 — ← Prev page 1 2 3 [4] 5 Next page →
| From | woodbrian77@gmail.com |
|---|---|
| Date | 2020-02-28 16:24 -0800 |
| Message-ID | <4c8bba30-c2db-4f38-8ae5-35c337baadd1@googlegroups.com> |
| In reply to | #72053 |
On Friday, February 28, 2020 at 5:37:35 PM UTC-6, Chris M. Thomasson wrote: > On 2/27/2020 8:19 PM, woodbrian77@gmail.com wrote: > > On Sunday, February 9, 2020 at 2:54:28 PM UTC-6, Chris M. Thomasson wrote: > >> On 10/30/2019 9:58 AM, woodbrian77@gmail.com wrote: > >>> Shalom > >>> > >>> Can you give me some suggestions on how to improve my > >>> repo: https://github.com/Ebenezer-group/onwards > >>> ? > >>> > >>> What do you think of recent changes to this file? > >>> https://github.com/Ebenezer-group/onwards/blob/master/src/cmw/tiers/cmwA.cc > >>> > >>> and a version from the end of September: > >>> https://github.com/Ebenezer-group/onwards/blob/9bc4c2646e7dc6421dfdcd9d1107d544c320a13a/src/cmw/tiers/cmwA.cc > >>> > >>> The number of lines hasn't changed much, but the size of the > >>> event loop, the most complicated part of the program, has been > >>> reduced by switching from TCP to SCTP. Thanks in advance. > >> > >> Iirc, you require a user to "register" by sending you an email with > >> their password in the clear? > > > > I plan to use Wireguard for encryption so it > > could be done after we have that set up. > > How are you storing those user passwords on your end? I hope your not > storing them in the clear... You can store the HMAC'ed result, keyed > with a salt or some random element. Then instead of comparing passwords > in the clear, you can compare hash digests. OK. I'm also thinking about this: https://www.reddit.com/r/WireGuard/comments/ewzxk4/no_password_protection_at_all/ Perhaps I don't need passwords beyond what Wireguard provides. Brian Ebenezer Enterprises - In G-d we trust. http://webEbenezer.net
[toc] | [prev] | [next] | [standalone]
| From | Melzzzzz <Melzzzzz@zzzzz.com> |
|---|---|
| Date | 2020-02-29 03:48 +0000 |
| Message-ID | <W9l6G.466483$Uz.342441@fx32.am4> |
| In reply to | #72054 |
On 2020-02-29, woodbrian77@gmail.com <woodbrian77@gmail.com> wrote: > On Friday, February 28, 2020 at 5:37:35 PM UTC-6, Chris M. Thomasson wrote: >> On 2/27/2020 8:19 PM, woodbrian77@gmail.com wrote: >> > On Sunday, February 9, 2020 at 2:54:28 PM UTC-6, Chris M. Thomasson wrote: >> >> On 10/30/2019 9:58 AM, woodbrian77@gmail.com wrote: >> >>> Shalom >> >>> >> >>> Can you give me some suggestions on how to improve my >> >>> repo: https://github.com/Ebenezer-group/onwards >> >>> ? >> >>> >> >>> What do you think of recent changes to this file? >> >>> https://github.com/Ebenezer-group/onwards/blob/master/src/cmw/tiers/cmwA.cc >> >>> >> >>> and a version from the end of September: >> >>> https://github.com/Ebenezer-group/onwards/blob/9bc4c2646e7dc6421dfdcd9d1107d544c320a13a/src/cmw/tiers/cmwA.cc >> >>> >> >>> The number of lines hasn't changed much, but the size of the >> >>> event loop, the most complicated part of the program, has been >> >>> reduced by switching from TCP to SCTP. Thanks in advance. >> >> >> >> Iirc, you require a user to "register" by sending you an email with >> >> their password in the clear? >> > >> > I plan to use Wireguard for encryption so it >> > could be done after we have that set up. sending passwords over mail is highly unsecure. No one does it any more. >> >> How are you storing those user passwords on your end? I hope your not >> storing them in the clear... You can store the HMAC'ed result, keyed >> with a salt or some random element. Then instead of comparing passwords >> in the clear, you can compare hash digests. > > OK. I'm also thinking about this: > https://www.reddit.com/r/WireGuard/comments/ewzxk4/no_password_protection_at_all/ > > Perhaps I don't need passwords beyond what Wireguard provides. Hm, no password is something like sending public keys? > > > Brian > Ebenezer Enterprises - In G-d we trust. > http://webEbenezer.net -- press any key to continue or any other to quit... U ničemu ja ne uživam kao u svom statusu INVALIDA -- Zli Zec Svi smo svedoci - oko 3 godine intenzivne propagande je dovoljno da jedan narod poludi -- Zli Zec Na divljem zapadu i nije bilo tako puno nasilja, upravo zato jer su svi bili naoruzani. -- Mladen Gogala
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2020-02-28 21:33 -0800 |
| Message-ID | <r3ct34$18p9$1@gioia.aioe.org> |
| In reply to | #72055 |
On 2/28/2020 7:48 PM, Melzzzzz wrote: > On 2020-02-29, woodbrian77@gmail.com <woodbrian77@gmail.com> wrote: >> On Friday, February 28, 2020 at 5:37:35 PM UTC-6, Chris M. Thomasson wrote: >>> On 2/27/2020 8:19 PM, woodbrian77@gmail.com wrote: >>>> On Sunday, February 9, 2020 at 2:54:28 PM UTC-6, Chris M. Thomasson wrote: >>>>> On 10/30/2019 9:58 AM, woodbrian77@gmail.com wrote: >>>>>> Shalom >>>>>> >>>>>> Can you give me some suggestions on how to improve my >>>>>> repo: https://github.com/Ebenezer-group/onwards >>>>>> ? >>>>>> >>>>>> What do you think of recent changes to this file? >>>>>> https://github.com/Ebenezer-group/onwards/blob/master/src/cmw/tiers/cmwA.cc >>>>>> >>>>>> and a version from the end of September: >>>>>> https://github.com/Ebenezer-group/onwards/blob/9bc4c2646e7dc6421dfdcd9d1107d544c320a13a/src/cmw/tiers/cmwA.cc >>>>>> >>>>>> The number of lines hasn't changed much, but the size of the >>>>>> event loop, the most complicated part of the program, has been >>>>>> reduced by switching from TCP to SCTP. Thanks in advance. >>>>> >>>>> Iirc, you require a user to "register" by sending you an email with >>>>> their password in the clear? >>>> >>>> I plan to use Wireguard for encryption so it >>>> could be done after we have that set up. > > sending passwords over mail is highly unsecure. No one does it any more. >>> >>> How are you storing those user passwords on your end? I hope your not >>> storing them in the clear... You can store the HMAC'ed result, keyed >>> with a salt or some random element. Then instead of comparing passwords >>> in the clear, you can compare hash digests. >> >> OK. I'm also thinking about this: >> https://www.reddit.com/r/WireGuard/comments/ewzxk4/no_password_protection_at_all/ >> >> Perhaps I don't need passwords beyond what Wireguard provides. > Hm, no password is something like sending public keys? Very Simple scheme... Password Setup: Use DH to setup temporary secure channel between server and a client. The client encrypts the password using this session and sends the ciphertext to the server. The server decrypts and hashes the password with a random salt. The secure channel is destroyed. The server stores the digest and the salt. Password Validation: Use DH to setup temporary secure channel between server and a client. The client encrypts the password using this session and sends the ciphertext to the server. The server decrypts, looks up your account, hashes the password with the stored random salt. The secure channel is destroyed. The server compares the stored digest vs the computed digest. This way, the users passwords do not have to be stored. This is just a simple way to do it. >> >> >> Brian >> Ebenezer Enterprises - In G-d we trust. >> http://webEbenezer.net > >
[toc] | [prev] | [next] | [standalone]
| From | Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> |
|---|---|
| Date | 2020-02-29 06:28 +0000 |
| Message-ID | <fwn6G.54127$_h7.15094@fx13.ams1> |
| In reply to | #72056 |
On 29/02/2020 05:33, Chris M. Thomasson wrote: > On 2/28/2020 7:48 PM, Melzzzzz wrote: >> On 2020-02-29, woodbrian77@gmail.com <woodbrian77@gmail.com> wrote: >>> On Friday, February 28, 2020 at 5:37:35 PM UTC-6, Chris M. Thomasson wrote: >>>> On 2/27/2020 8:19 PM, woodbrian77@gmail.com wrote: >>>>> On Sunday, February 9, 2020 at 2:54:28 PM UTC-6, Chris M. Thomasson wrote: >>>>>> On 10/30/2019 9:58 AM, woodbrian77@gmail.com wrote: >>>>>>> Shalom >>>>>>> >>>>>>> Can you give me some suggestions on how to improve my >>>>>>> repo: https://github.com/Ebenezer-group/onwards >>>>>>> ? >>>>>>> >>>>>>> What do you think of recent changes to this file? >>>>>>> https://github.com/Ebenezer-group/onwards/blob/master/src/cmw/tiers/cmwA.cc >>>>>>> >>>>>>> and a version from the end of September: >>>>>>> https://github.com/Ebenezer-group/onwards/blob/9bc4c2646e7dc6421dfdcd9d1107d544c320a13a/src/cmw/tiers/cmwA.cc >>>>>>> >>>>>>> The number of lines hasn't changed much, but the size of the >>>>>>> event loop, the most complicated part of the program, has been >>>>>>> reduced by switching from TCP to SCTP. Thanks in advance. >>>>>> >>>>>> Iirc, you require a user to "register" by sending you an email with >>>>>> their password in the clear? >>>>> >>>>> I plan to use Wireguard for encryption so it >>>>> could be done after we have that set up. >> >> sending passwords over mail is highly unsecure. No one does it any more. >>>> >>>> How are you storing those user passwords on your end? I hope your not >>>> storing them in the clear... You can store the HMAC'ed result, keyed >>>> with a salt or some random element. Then instead of comparing passwords >>>> in the clear, you can compare hash digests. >>> >>> OK. I'm also thinking about this: >>> https://www.reddit.com/r/WireGuard/comments/ewzxk4/no_password_protection_at_all/ >>> >>> Perhaps I don't need passwords beyond what Wireguard provides. >> Hm, no password is something like sending public keys? > > Very Simple scheme... > > Password Setup: > > Use DH to setup temporary secure channel between server and a client. > > The client encrypts the password using this session and sends the ciphertext to the server. > > The server decrypts and hashes the password with a random salt. > > The secure channel is destroyed. > > The server stores the digest and the salt. > > > Password Validation: > > Use DH to setup temporary secure channel between server and a client. > > The client encrypts the password using this session and sends the ciphertext to the server. > > The server decrypts, looks up your account, hashes the password with the stored random salt. NO! Do not send the password to the fucking server, hash on the fucking CLIENT and send the fucking HASH to the fucking server. /Flibble -- "Snakes didn't evolve, instead talking snakes with legs changed into snakes." - Rick C. Hodgin “You won’t burn in hell. But be nice anyway.” – Ricky Gervais “I see Atheists are fighting and killing each other again, over who doesn’t believe in any God the most. Oh, no..wait.. that never happens.” – Ricky Gervais "Suppose it's all true, and you walk up to the pearly gates, and are confronted by God," Byrne asked on his show The Meaning of Life. "What will Stephen Fry say to him, her, or it?" "I'd say, bone cancer in children? What's that about?" Fry replied. "How dare you? How dare you create a world to which there is such misery that is not our fault. It's not right, it's utterly, utterly evil." "Why should I respect a capricious, mean-minded, stupid God who creates a world that is so full of injustice and pain. That's what I would say."
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2020-02-28 22:34 -0800 |
| Message-ID | <r3d0kv$1nc1$1@gioia.aioe.org> |
| In reply to | #72057 |
On 2/28/2020 10:28 PM, Mr Flibble wrote: > On 29/02/2020 05:33, Chris M. Thomasson wrote: >> On 2/28/2020 7:48 PM, Melzzzzz wrote: >>> On 2020-02-29, woodbrian77@gmail.com <woodbrian77@gmail.com> wrote: >>>> On Friday, February 28, 2020 at 5:37:35 PM UTC-6, Chris M. Thomasson >>>> wrote: >>>>> On 2/27/2020 8:19 PM, woodbrian77@gmail.com wrote: >>>>>> On Sunday, February 9, 2020 at 2:54:28 PM UTC-6, Chris M. >>>>>> Thomasson wrote: >>>>>>> On 10/30/2019 9:58 AM, woodbrian77@gmail.com wrote: >>>>>>>> Shalom >>>>>>>> >>>>>>>> Can you give me some suggestions on how to improve my >>>>>>>> repo: https://github.com/Ebenezer-group/onwards >>>>>>>> ? >>>>>>>> >>>>>>>> What do you think of recent changes to this file? >>>>>>>> https://github.com/Ebenezer-group/onwards/blob/master/src/cmw/tiers/cmwA.cc >>>>>>>> >>>>>>>> >>>>>>>> and a version from the end of September: >>>>>>>> https://github.com/Ebenezer-group/onwards/blob/9bc4c2646e7dc6421dfdcd9d1107d544c320a13a/src/cmw/tiers/cmwA.cc >>>>>>>> >>>>>>>> >>>>>>>> The number of lines hasn't changed much, but the size of the >>>>>>>> event loop, the most complicated part of the program, has been >>>>>>>> reduced by switching from TCP to SCTP. Thanks in advance. >>>>>>> >>>>>>> Iirc, you require a user to "register" by sending you an email with >>>>>>> their password in the clear? >>>>>> >>>>>> I plan to use Wireguard for encryption so it >>>>>> could be done after we have that set up. >>> >>> sending passwords over mail is highly unsecure. No one does it any more. >>>>> >>>>> How are you storing those user passwords on your end? I hope your not >>>>> storing them in the clear... You can store the HMAC'ed result, keyed >>>>> with a salt or some random element. Then instead of comparing >>>>> passwords >>>>> in the clear, you can compare hash digests. >>>> >>>> OK. I'm also thinking about this: >>>> https://www.reddit.com/r/WireGuard/comments/ewzxk4/no_password_protection_at_all/ >>>> >>>> >>>> Perhaps I don't need passwords beyond what Wireguard provides. >>> Hm, no password is something like sending public keys? >> >> Very Simple scheme... >> >> Password Setup: >> >> Use DH to setup temporary secure channel between server and a client. >> >> The client encrypts the password using this session and sends the >> ciphertext to the server. >> >> The server decrypts and hashes the password with a random salt. >> >> The secure channel is destroyed. >> >> The server stores the digest and the salt. >> >> >> Password Validation: >> >> Use DH to setup temporary secure channel between server and a client. >> >> The client encrypts the password using this session and sends the >> ciphertext to the server. >> >> The server decrypts, looks up your account, hashes the password with >> the stored random salt. > > NO! Do not send the password to the fucking server, hash on the fucking > CLIENT and send the fucking HASH to the fucking server.' Okay. I was thinking of sending an encrypted password using a DH secure channel. We can most certainly hash on the client, then send the digest to the server using a secure DH? > > /Flibble >
[toc] | [prev] | [next] | [standalone]
| From | Melzzzzz <Melzzzzz@zzzzz.com> |
|---|---|
| Date | 2020-02-29 06:51 +0000 |
| Message-ID | <DRn6G.1466760$GFe.1466664@fx12.am4> |
| In reply to | #72058 |
On 2020-02-29, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote: > On 2/28/2020 10:28 PM, Mr Flibble wrote: >> On 29/02/2020 05:33, Chris M. Thomasson wrote: >>> On 2/28/2020 7:48 PM, Melzzzzz wrote: >>>> On 2020-02-29, woodbrian77@gmail.com <woodbrian77@gmail.com> wrote: >>>>> On Friday, February 28, 2020 at 5:37:35 PM UTC-6, Chris M. Thomasson >>>>> wrote: >>>>>> On 2/27/2020 8:19 PM, woodbrian77@gmail.com wrote: >>>>>>> On Sunday, February 9, 2020 at 2:54:28 PM UTC-6, Chris M. >>>>>>> Thomasson wrote: >>>>>>>> On 10/30/2019 9:58 AM, woodbrian77@gmail.com wrote: >>>>>>>>> Shalom >>>>>>>>> >>>>>>>>> Can you give me some suggestions on how to improve my >>>>>>>>> repo: https://github.com/Ebenezer-group/onwards >>>>>>>>> ? >>>>>>>>> >>>>>>>>> What do you think of recent changes to this file? >>>>>>>>> https://github.com/Ebenezer-group/onwards/blob/master/src/cmw/tiers/cmwA.cc >>>>>>>>> >>>>>>>>> >>>>>>>>> and a version from the end of September: >>>>>>>>> https://github.com/Ebenezer-group/onwards/blob/9bc4c2646e7dc6421dfdcd9d1107d544c320a13a/src/cmw/tiers/cmwA.cc >>>>>>>>> >>>>>>>>> >>>>>>>>> The number of lines hasn't changed much, but the size of the >>>>>>>>> event loop, the most complicated part of the program, has been >>>>>>>>> reduced by switching from TCP to SCTP. Thanks in advance. >>>>>>>> >>>>>>>> Iirc, you require a user to "register" by sending you an email with >>>>>>>> their password in the clear? >>>>>>> >>>>>>> I plan to use Wireguard for encryption so it >>>>>>> could be done after we have that set up. >>>> >>>> sending passwords over mail is highly unsecure. No one does it any more. >>>>>> >>>>>> How are you storing those user passwords on your end? I hope your not >>>>>> storing them in the clear... You can store the HMAC'ed result, keyed >>>>>> with a salt or some random element. Then instead of comparing >>>>>> passwords >>>>>> in the clear, you can compare hash digests. >>>>> >>>>> OK. I'm also thinking about this: >>>>> https://www.reddit.com/r/WireGuard/comments/ewzxk4/no_password_protection_at_all/ >>>>> >>>>> >>>>> Perhaps I don't need passwords beyond what Wireguard provides. >>>> Hm, no password is something like sending public keys? >>> >>> Very Simple scheme... >>> >>> Password Setup: >>> >>> Use DH to setup temporary secure channel between server and a client. >>> >>> The client encrypts the password using this session and sends the >>> ciphertext to the server. >>> >>> The server decrypts and hashes the password with a random salt. >>> >>> The secure channel is destroyed. >>> >>> The server stores the digest and the salt. >>> >>> >>> Password Validation: >>> >>> Use DH to setup temporary secure channel between server and a client. >>> >>> The client encrypts the password using this session and sends the >>> ciphertext to the server. >>> >>> The server decrypts, looks up your account, hashes the password with >>> the stored random salt. >> >> NO! Do not send the password to the fucking server, hash on the fucking >> CLIENT and send the fucking HASH to the fucking server.' > > Okay. I was thinking of sending an encrypted password using a DH secure > channel. We can most certainly hash on the client, then send the digest > to the server using a secure DH? When using encrypted protocol it is same. When attacker has hash it is same as plain text. > >> >> /Flibble >> > -- press any key to continue or any other to quit... U ničemu ja ne uživam kao u svom statusu INVALIDA -- Zli Zec Svi smo svedoci - oko 3 godine intenzivne propagande je dovoljno da jedan narod poludi -- Zli Zec Na divljem zapadu i nije bilo tako puno nasilja, upravo zato jer su svi bili naoruzani. -- Mladen Gogala
[toc] | [prev] | [next] | [standalone]
| From | Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> |
|---|---|
| Date | 2020-02-29 07:34 +0000 |
| Message-ID | <_to6G.60660$4z5.47573@fx30.ams1> |
| In reply to | #72060 |
On 29/02/2020 06:51, Melzzzzz wrote: > On 2020-02-29, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote: >> On 2/28/2020 10:28 PM, Mr Flibble wrote: >>> On 29/02/2020 05:33, Chris M. Thomasson wrote: >>>> On 2/28/2020 7:48 PM, Melzzzzz wrote: >>>>> On 2020-02-29, woodbrian77@gmail.com <woodbrian77@gmail.com> wrote: >>>>>> On Friday, February 28, 2020 at 5:37:35 PM UTC-6, Chris M. Thomasson >>>>>> wrote: >>>>>>> On 2/27/2020 8:19 PM, woodbrian77@gmail.com wrote: >>>>>>>> On Sunday, February 9, 2020 at 2:54:28 PM UTC-6, Chris M. >>>>>>>> Thomasson wrote: >>>>>>>>> On 10/30/2019 9:58 AM, woodbrian77@gmail.com wrote: >>>>>>>>>> Shalom >>>>>>>>>> >>>>>>>>>> Can you give me some suggestions on how to improve my >>>>>>>>>> repo: https://github.com/Ebenezer-group/onwards >>>>>>>>>> ? >>>>>>>>>> >>>>>>>>>> What do you think of recent changes to this file? >>>>>>>>>> https://github.com/Ebenezer-group/onwards/blob/master/src/cmw/tiers/cmwA.cc >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> and a version from the end of September: >>>>>>>>>> https://github.com/Ebenezer-group/onwards/blob/9bc4c2646e7dc6421dfdcd9d1107d544c320a13a/src/cmw/tiers/cmwA.cc >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> The number of lines hasn't changed much, but the size of the >>>>>>>>>> event loop, the most complicated part of the program, has been >>>>>>>>>> reduced by switching from TCP to SCTP. Thanks in advance. >>>>>>>>> >>>>>>>>> Iirc, you require a user to "register" by sending you an email with >>>>>>>>> their password in the clear? >>>>>>>> >>>>>>>> I plan to use Wireguard for encryption so it >>>>>>>> could be done after we have that set up. >>>>> >>>>> sending passwords over mail is highly unsecure. No one does it any more. >>>>>>> >>>>>>> How are you storing those user passwords on your end? I hope your not >>>>>>> storing them in the clear... You can store the HMAC'ed result, keyed >>>>>>> with a salt or some random element. Then instead of comparing >>>>>>> passwords >>>>>>> in the clear, you can compare hash digests. >>>>>> >>>>>> OK. I'm also thinking about this: >>>>>> https://www.reddit.com/r/WireGuard/comments/ewzxk4/no_password_protection_at_all/ >>>>>> >>>>>> >>>>>> Perhaps I don't need passwords beyond what Wireguard provides. >>>>> Hm, no password is something like sending public keys? >>>> >>>> Very Simple scheme... >>>> >>>> Password Setup: >>>> >>>> Use DH to setup temporary secure channel between server and a client. >>>> >>>> The client encrypts the password using this session and sends the >>>> ciphertext to the server. >>>> >>>> The server decrypts and hashes the password with a random salt. >>>> >>>> The secure channel is destroyed. >>>> >>>> The server stores the digest and the salt. >>>> >>>> >>>> Password Validation: >>>> >>>> Use DH to setup temporary secure channel between server and a client. >>>> >>>> The client encrypts the password using this session and sends the >>>> ciphertext to the server. >>>> >>>> The server decrypts, looks up your account, hashes the password with >>>> the stored random salt. >>> >>> NO! Do not send the password to the fucking server, hash on the fucking >>> CLIENT and send the fucking HASH to the fucking server.' >> >> Okay. I was thinking of sending an encrypted password using a DH secure >> channel. We can most certainly hash on the client, then send the digest >> to the server using a secure DH? > > When using encrypted protocol it is same. When attacker has hash it is > same as plain text. You are missing the point: people use the same password for different things: if the hash is compromised it only compromises access to this particular server; also you cannot gaurantee that lemons working on the server code don't log it by mistake. NEVER send password in the clear from the CLIENT computer even over encrpypted links. Clue: you can hash a hash. /Flibble -- "Snakes didn't evolve, instead talking snakes with legs changed into snakes." - Rick C. Hodgin “You won’t burn in hell. But be nice anyway.” – Ricky Gervais “I see Atheists are fighting and killing each other again, over who doesn’t believe in any God the most. Oh, no..wait.. that never happens.” – Ricky Gervais "Suppose it's all true, and you walk up to the pearly gates, and are confronted by God," Byrne asked on his show The Meaning of Life. "What will Stephen Fry say to him, her, or it?" "I'd say, bone cancer in children? What's that about?" Fry replied. "How dare you? How dare you create a world to which there is such misery that is not our fault. It's not right, it's utterly, utterly evil." "Why should I respect a capricious, mean-minded, stupid God who creates a world that is so full of injustice and pain. That's what I would say."
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2020-02-28 23:40 -0800 |
| Message-ID | <r3d4ho$816$2@gioia.aioe.org> |
| In reply to | #72062 |
On 2/28/2020 11:34 PM, Mr Flibble wrote: > On 29/02/2020 06:51, Melzzzzz wrote: >> On 2020-02-29, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote: >>> On 2/28/2020 10:28 PM, Mr Flibble wrote: >>>> On 29/02/2020 05:33, Chris M. Thomasson wrote: >>>>> On 2/28/2020 7:48 PM, Melzzzzz wrote: >>>>>> On 2020-02-29, woodbrian77@gmail.com <woodbrian77@gmail.com> wrote: >>>>>>> On Friday, February 28, 2020 at 5:37:35 PM UTC-6, Chris M. Thomasson >>>>>>> wrote: >>>>>>>> On 2/27/2020 8:19 PM, woodbrian77@gmail.com wrote: >>>>>>>>> On Sunday, February 9, 2020 at 2:54:28 PM UTC-6, Chris M. >>>>>>>>> Thomasson wrote: >>>>>>>>>> On 10/30/2019 9:58 AM, woodbrian77@gmail.com wrote: >>>>>>>>>>> Shalom >>>>>>>>>>> >>>>>>>>>>> Can you give me some suggestions on how to improve my >>>>>>>>>>> repo: https://github.com/Ebenezer-group/onwards >>>>>>>>>>> ? >>>>>>>>>>> >>>>>>>>>>> What do you think of recent changes to this file? >>>>>>>>>>> https://github.com/Ebenezer-group/onwards/blob/master/src/cmw/tiers/cmwA.cc >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> and a version from the end of September: >>>>>>>>>>> https://github.com/Ebenezer-group/onwards/blob/9bc4c2646e7dc6421dfdcd9d1107d544c320a13a/src/cmw/tiers/cmwA.cc >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> The number of lines hasn't changed much, but the size of the >>>>>>>>>>> event loop, the most complicated part of the program, has been >>>>>>>>>>> reduced by switching from TCP to SCTP. Thanks in advance. >>>>>>>>>> >>>>>>>>>> Iirc, you require a user to "register" by sending you an email >>>>>>>>>> with >>>>>>>>>> their password in the clear? >>>>>>>>> >>>>>>>>> I plan to use Wireguard for encryption so it >>>>>>>>> could be done after we have that set up. >>>>>> >>>>>> sending passwords over mail is highly unsecure. No one does it any >>>>>> more. >>>>>>>> >>>>>>>> How are you storing those user passwords on your end? I hope >>>>>>>> your not >>>>>>>> storing them in the clear... You can store the HMAC'ed result, >>>>>>>> keyed >>>>>>>> with a salt or some random element. Then instead of comparing >>>>>>>> passwords >>>>>>>> in the clear, you can compare hash digests. >>>>>>> >>>>>>> OK. I'm also thinking about this: >>>>>>> https://www.reddit.com/r/WireGuard/comments/ewzxk4/no_password_protection_at_all/ >>>>>>> >>>>>>> >>>>>>> >>>>>>> Perhaps I don't need passwords beyond what Wireguard provides. >>>>>> Hm, no password is something like sending public keys? >>>>> >>>>> Very Simple scheme... >>>>> >>>>> Password Setup: >>>>> >>>>> Use DH to setup temporary secure channel between server and a client. >>>>> >>>>> The client encrypts the password using this session and sends the >>>>> ciphertext to the server. >>>>> >>>>> The server decrypts and hashes the password with a random salt. >>>>> >>>>> The secure channel is destroyed. >>>>> >>>>> The server stores the digest and the salt. >>>>> >>>>> >>>>> Password Validation: >>>>> >>>>> Use DH to setup temporary secure channel between server and a client. >>>>> >>>>> The client encrypts the password using this session and sends the >>>>> ciphertext to the server. >>>>> >>>>> The server decrypts, looks up your account, hashes the password with >>>>> the stored random salt. >>>> >>>> NO! Do not send the password to the fucking server, hash on the fucking >>>> CLIENT and send the fucking HASH to the fucking server.' >>> >>> Okay. I was thinking of sending an encrypted password using a DH secure >>> channel. We can most certainly hash on the client, then send the digest >>> to the server using a secure DH? >> >> When using encrypted protocol it is same. When attacker has hash it is >> same as plain text. > > You are missing the point: people use the same password for different > things: if the hash is compromised it only compromises access to this > particular server; also > you cannot gaurantee that lemons working on the server code don't log it > by mistake. NEVER send password in the clear from the CLIENT computer > even over encrpypted links. It must use encrpypted links regardless. > Clue: you can hash a hash. > > /Flibble >
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2020-03-01 14:46 +0100 |
| Message-ID | <r3geba$u4e$1@dont-email.me> |
| In reply to | #72062 |
On 29/02/2020 08:34, Mr Flibble wrote: > On 29/02/2020 06:51, Melzzzzz wrote: >> On 2020-02-29, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote: >>> >>> Okay. I was thinking of sending an encrypted password using a DH secure >>> channel. We can most certainly hash on the client, then send the digest >>> to the server using a secure DH? >> >> When using encrypted protocol it is same. When attacker has hash it is >> same as plain text. > > You are missing the point: people use the same password for different > things: if the hash is compromised it only compromises access to this > particular server; also > you cannot gaurantee that lemons working on the server code don't log it > by mistake. NEVER send password in the clear from the CLIENT computer > even over encrpypted links. > Clue: you can hash a hash. > Exactly. It is always surprising how many people miss this point. (And it should be needless to add that you should pick a good, random salt.) The bad guys don't break into Facebook, Google, banks, and the like by hacking those servers and reading out their data. They break into some numpty web site that has stored user names, email addresses and clear text passwords (because the muppet running them thinks Wireguard or DH is magic that keeps it all safe). Then they guess that the user has the same password on other services. In virtually all cases, a standard https connection is secure enough for transferring the password hash from the client to the server. It is almost certainly better than making up your own system because you have heard that Diffie-Hellman key exchange is good, or because you have read about Wireguard while totally misunderstanding its purpose. And after the initial transfer of the hash, you never have to transfer it again, meaning the bad guys only have once chance to eavesdrop on it.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2020-03-01 12:59 -0800 |
| Message-ID | <r3h7ob$16f0$1@gioia.aioe.org> |
| In reply to | #72069 |
On 3/1/2020 5:46 AM, David Brown wrote: > On 29/02/2020 08:34, Mr Flibble wrote: >> On 29/02/2020 06:51, Melzzzzz wrote: >>> On 2020-02-29, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote: > >>>> >>>> Okay. I was thinking of sending an encrypted password using a DH secure >>>> channel. We can most certainly hash on the client, then send the digest >>>> to the server using a secure DH? >>> >>> When using encrypted protocol it is same. When attacker has hash it is >>> same as plain text. >> >> You are missing the point: people use the same password for different >> things: if the hash is compromised it only compromises access to this >> particular server; also >> you cannot gaurantee that lemons working on the server code don't log >> it by mistake. NEVER send password in the clear from the CLIENT >> computer even over encrpypted links. >> Clue: you can hash a hash. >> > > Exactly. It is always surprising how many people miss this point. (And > it should be needless to add that you should pick a good, random salt.) > > The bad guys don't break into Facebook, Google, banks, and the like by > hacking those servers and reading out their data. They break into some > numpty web site that has stored user names, email addresses and clear > text passwords (because the muppet running them thinks Wireguard or DH > is magic that keeps it all safe). Then they guess that the user has the > same password on other services. > > In virtually all cases, a standard https connection is secure enough for > transferring the password hash from the client to the server. Agreed. > It is > almost certainly better than making up your own system because you have > heard that Diffie-Hellman key exchange is good Actually, DH key exchange can be very dangerous. One needs to know how to use it. Large secure primes come to mind. , or because you have read > about Wireguard while totally misunderstanding its purpose. > > And after the initial transfer of the hash, you never have to transfer > it again, meaning the bad guys only have once chance to eavesdrop on it. >
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2020-03-01 22:47 +0100 |
| Message-ID | <r3hai2$78g$1@dont-email.me> |
| In reply to | #72072 |
On 01/03/2020 21:59, Chris M. Thomasson wrote: > On 3/1/2020 5:46 AM, David Brown wrote: >> On 29/02/2020 08:34, Mr Flibble wrote: >>> On 29/02/2020 06:51, Melzzzzz wrote: >>>> On 2020-02-29, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> >>>> wrote: >> >>>>> >>>>> Okay. I was thinking of sending an encrypted password using a DH >>>>> secure >>>>> channel. We can most certainly hash on the client, then send the >>>>> digest >>>>> to the server using a secure DH? >>>> >>>> When using encrypted protocol it is same. When attacker has hash it is >>>> same as plain text. >>> >>> You are missing the point: people use the same password for different >>> things: if the hash is compromised it only compromises access to this >>> particular server; also >>> you cannot gaurantee that lemons working on the server code don't log >>> it by mistake. NEVER send password in the clear from the CLIENT >>> computer even over encrpypted links. >>> Clue: you can hash a hash. >>> >> >> Exactly. It is always surprising how many people miss this point. >> (And it should be needless to add that you should pick a good, random >> salt.) >> >> The bad guys don't break into Facebook, Google, banks, and the like by >> hacking those servers and reading out their data. They break into >> some numpty web site that has stored user names, email addresses and >> clear text passwords (because the muppet running them thinks Wireguard >> or DH is magic that keeps it all safe). Then they guess that the user >> has the same password on other services. >> >> In virtually all cases, a standard https connection is secure enough >> for transferring the password hash from the client to the server. > > Agreed. > > >> It is almost certainly better than making up your own system because >> you have heard that Diffie-Hellman key exchange is good > > Actually, DH key exchange can be very dangerous. One needs to know how > to use it. Large secure primes come to mind. > Friendly reminder - it was /you/ who brought up DH! Anything in the cryptographic world can be "dangerous". A little knowledge can be a very bad thing here. You are far better off forgetting you ever heard of "Diffie-Hellman" or key exchange - use a good TLS implementation and let people who know what they are doing implement the security. (The authors of such software are not infallible either, so track updates and fixes for the software.)
[toc] | [prev] | [next] | [standalone]
| From | red floyd <no.spam@its.invalid> |
|---|---|
| Date | 2020-03-01 22:14 -0800 |
| Message-ID | <r3i893$9av$1@redfloyd.dont-email.me> |
| In reply to | #72073 |
On 3/1/20 1:47 PM, David Brown wrote: > On 01/03/2020 21:59, Chris M. Thomasson wrote: >> On 3/1/2020 5:46 AM, David Brown wrote: >>> On 29/02/2020 08:34, Mr Flibble wrote: >>>> On 29/02/2020 06:51, Melzzzzz wrote: >>>>> On 2020-02-29, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> >>>>> wrote: >>> >>>>>> >>>>>> Okay. I was thinking of sending an encrypted password using a DH >>>>>> secure >>>>>> channel. We can most certainly hash on the client, then send the >>>>>> digest >>>>>> to the server using a secure DH? >>>>> >>>>> When using encrypted protocol it is same. When attacker has hash it is >>>>> same as plain text. >>>> >>>> You are missing the point: people use the same password for >>>> different things: if the hash is compromised it only compromises >>>> access to this particular server; also >>>> you cannot gaurantee that lemons working on the server code don't >>>> log it by mistake. NEVER send password in the clear from the CLIENT >>>> computer even over encrpypted links. >>>> Clue: you can hash a hash. >>>> >>> >>> Exactly. It is always surprising how many people miss this point. >>> (And it should be needless to add that you should pick a good, random >>> salt.) >>> >>> The bad guys don't break into Facebook, Google, banks, and the like >>> by hacking those servers and reading out their data. They break into >>> some numpty web site that has stored user names, email addresses and >>> clear text passwords (because the muppet running them thinks >>> Wireguard or DH is magic that keeps it all safe). Then they guess >>> that the user has the same password on other services. >>> >>> In virtually all cases, a standard https connection is secure enough >>> for transferring the password hash from the client to the server. >> >> Agreed. >> >> >>> It is almost certainly better than making up your own system because >>> you have heard that Diffie-Hellman key exchange is good >> >> Actually, DH key exchange can be very dangerous. One needs to know how >> to use it. Large secure primes come to mind. >> > > Friendly reminder - it was /you/ who brought up DH! > > Anything in the cryptographic world can be "dangerous". A little > knowledge can be a very bad thing here. You are far better off > forgetting you ever heard of "Diffie-Hellman" or key exchange - use a > good TLS implementation and let people who know what they are doing > implement the security. (The authors of such software are not > infallible either, so track updates and fixes for the software.) > > Crypto is hard. Really hard. Do not -- repeat DO NOT -- attempt to write your own crypto. Use something like OpenSSL, LibreSSL, or Guttman's Cryptlib for the crypto and secure channel.
[toc] | [prev] | [next] | [standalone]
| From | woodbrian77@gmail.com |
|---|---|
| Date | 2020-03-03 08:06 -0800 |
| Message-ID | <4b72fa1e-4efc-4b97-9334-9ecd6a199e51@googlegroups.com> |
| In reply to | #72080 |
On Monday, March 2, 2020 at 12:15:09 AM UTC-6, red floyd wrote: > On 3/1/20 1:47 PM, David Brown wrote: > > On 01/03/2020 21:59, Chris M. Thomasson wrote: > >> On 3/1/2020 5:46 AM, David Brown wrote: > >>> On 29/02/2020 08:34, Mr Flibble wrote: > >>>> On 29/02/2020 06:51, Melzzzzz wrote: > >>>>> On 2020-02-29, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> > >>>>> wrote: > >>> > >>>>>> > >>>>>> Okay. I was thinking of sending an encrypted password using a DH > >>>>>> secure > >>>>>> channel. We can most certainly hash on the client, then send the > >>>>>> digest > >>>>>> to the server using a secure DH? > >>>>> > >>>>> When using encrypted protocol it is same. When attacker has hash it is > >>>>> same as plain text. > >>>> > >>>> You are missing the point: people use the same password for > >>>> different things: if the hash is compromised it only compromises > >>>> access to this particular server; also > >>>> you cannot gaurantee that lemons working on the server code don't > >>>> log it by mistake. NEVER send password in the clear from the CLIENT > >>>> computer even over encrpypted links. > >>>> Clue: you can hash a hash. > >>>> > >>> > >>> Exactly. It is always surprising how many people miss this point. > >>> (And it should be needless to add that you should pick a good, random > >>> salt.) > >>> > >>> The bad guys don't break into Facebook, Google, banks, and the like > >>> by hacking those servers and reading out their data. They break into > >>> some numpty web site that has stored user names, email addresses and > >>> clear text passwords (because the muppet running them thinks > >>> Wireguard or DH is magic that keeps it all safe). Then they guess > >>> that the user has the same password on other services. > >>> > >>> In virtually all cases, a standard https connection is secure enough > >>> for transferring the password hash from the client to the server. > >> > >> Agreed. > >> > >> > >>> It is almost certainly better than making up your own system because > >>> you have heard that Diffie-Hellman key exchange is good > >> > >> Actually, DH key exchange can be very dangerous. One needs to know how > >> to use it. Large secure primes come to mind. > >> > > > > Friendly reminder - it was /you/ who brought up DH! > > > > Anything in the cryptographic world can be "dangerous". A little > > knowledge can be a very bad thing here. You are far better off > > forgetting you ever heard of "Diffie-Hellman" or key exchange - use a > > good TLS implementation and let people who know what they are doing > > implement the security. (The authors of such software are not > > infallible either, so track updates and fixes for the software.) > > > > > > Crypto is hard. Really hard. Do not -- repeat DO NOT -- attempt > to write your own crypto. Use something like OpenSSL, LibreSSL, > or Guttman's Cryptlib for the crypto and secure channel. I'm going to use Wireguard as a first step. Brian Ebenezer Enterprises https://github.com/Ebenezer-group/onwards
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2020-03-02 13:21 -0800 |
| Message-ID | <r3jtd3$1q8s$1@gioia.aioe.org> |
| In reply to | #72073 |
On 3/1/2020 1:47 PM, David Brown wrote: > On 01/03/2020 21:59, Chris M. Thomasson wrote: >> On 3/1/2020 5:46 AM, David Brown wrote: >>> On 29/02/2020 08:34, Mr Flibble wrote: >>>> On 29/02/2020 06:51, Melzzzzz wrote: >>>>> On 2020-02-29, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> >>>>> wrote: >>> >>>>>> >>>>>> Okay. I was thinking of sending an encrypted password using a DH >>>>>> secure >>>>>> channel. We can most certainly hash on the client, then send the >>>>>> digest >>>>>> to the server using a secure DH? >>>>> >>>>> When using encrypted protocol it is same. When attacker has hash it is >>>>> same as plain text. >>>> >>>> You are missing the point: people use the same password for >>>> different things: if the hash is compromised it only compromises >>>> access to this particular server; also >>>> you cannot gaurantee that lemons working on the server code don't >>>> log it by mistake. NEVER send password in the clear from the CLIENT >>>> computer even over encrpypted links. >>>> Clue: you can hash a hash. >>>> >>> >>> Exactly. It is always surprising how many people miss this point. >>> (And it should be needless to add that you should pick a good, random >>> salt.) >>> >>> The bad guys don't break into Facebook, Google, banks, and the like >>> by hacking those servers and reading out their data. They break into >>> some numpty web site that has stored user names, email addresses and >>> clear text passwords (because the muppet running them thinks >>> Wireguard or DH is magic that keeps it all safe). Then they guess >>> that the user has the same password on other services. >>> >>> In virtually all cases, a standard https connection is secure enough >>> for transferring the password hash from the client to the server. >> >> Agreed. >> >> >>> It is almost certainly better than making up your own system because >>> you have heard that Diffie-Hellman key exchange is good >> >> Actually, DH key exchange can be very dangerous. One needs to know how >> to use it. Large secure primes come to mind. >> > > Friendly reminder - it was /you/ who brought up DH! Indeed I did. It was simply meant for the OP to take a look at; study. Imvvvho, its a good algorihtm to learn, at least. > Anything in the cryptographic world can be "dangerous". A little > knowledge can be a very bad thing here. You are far better off > forgetting you ever heard of "Diffie-Hellman" or key exchange - use a > good TLS implementation and let people who know what they are doing > implement the security. (The authors of such software are not > infallible either, so track updates and fixes for the software.) Fwiw, I have an experimental symmetric cipher. If you get some really free time perhaps you can take a look at it: https://groups.google.com/d/topic/comp.lang.c/a53VxN8cwkY/discussion http://funwithfractals.atspace.cc/ct_cipher https://pastebin.com/raw/feUnA3kP (C version with hardcoded secret key) I can get it to work with traditional HMAC, however its way too slow. Using an optimized HMAC that can take a digest without destroying its internal state makes things go a lot faster.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2020-03-02 13:24 -0800 |
| Message-ID | <r3jtim$1q8s$2@gioia.aioe.org> |
| In reply to | #72083 |
On 3/2/2020 1:21 PM, Chris M. Thomasson wrote: > On 3/1/2020 1:47 PM, David Brown wrote: >> On 01/03/2020 21:59, Chris M. Thomasson wrote: >>> On 3/1/2020 5:46 AM, David Brown wrote: >>>> On 29/02/2020 08:34, Mr Flibble wrote: >>>>> On 29/02/2020 06:51, Melzzzzz wrote: >>>>>> On 2020-02-29, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> >>>>>> wrote: >>>> >>>>>>> >>>>>>> Okay. I was thinking of sending an encrypted password using a DH >>>>>>> secure >>>>>>> channel. We can most certainly hash on the client, then send the >>>>>>> digest >>>>>>> to the server using a secure DH? >>>>>> >>>>>> When using encrypted protocol it is same. When attacker has hash >>>>>> it is >>>>>> same as plain text. >>>>> >>>>> You are missing the point: people use the same password for >>>>> different things: if the hash is compromised it only compromises >>>>> access to this particular server; also >>>>> you cannot gaurantee that lemons working on the server code don't >>>>> log it by mistake. NEVER send password in the clear from the CLIENT >>>>> computer even over encrpypted links. >>>>> Clue: you can hash a hash. >>>>> >>>> >>>> Exactly. It is always surprising how many people miss this point. >>>> (And it should be needless to add that you should pick a good, >>>> random salt.) >>>> >>>> The bad guys don't break into Facebook, Google, banks, and the like >>>> by hacking those servers and reading out their data. They break >>>> into some numpty web site that has stored user names, email >>>> addresses and clear text passwords (because the muppet running them >>>> thinks Wireguard or DH is magic that keeps it all safe). Then they >>>> guess that the user has the same password on other services. >>>> >>>> In virtually all cases, a standard https connection is secure enough >>>> for transferring the password hash from the client to the server. >>> >>> Agreed. >>> >>> >>>> It is almost certainly better than making up your own system because >>>> you have heard that Diffie-Hellman key exchange is good >>> >>> Actually, DH key exchange can be very dangerous. One needs to know >>> how to use it. Large secure primes come to mind. >>> >> >> Friendly reminder - it was /you/ who brought up DH! > > Indeed I did. It was simply meant for the OP to take a look at; study. > Imvvvho, its a good algorihtm to learn, at least. > > >> Anything in the cryptographic world can be "dangerous". A little >> knowledge can be a very bad thing here. You are far better off >> forgetting you ever heard of "Diffie-Hellman" or key exchange - use a >> good TLS implementation and let people who know what they are doing >> implement the security. (The authors of such software are not >> infallible either, so track updates and fixes for the software.) > > Fwiw, I have an experimental symmetric cipher. If you get some really > free time perhaps you can take a look at it: > > https://groups.google.com/d/topic/comp.lang.c/a53VxN8cwkY/discussion > > http://funwithfractals.atspace.cc/ct_cipher > > https://pastebin.com/raw/feUnA3kP > (C version with hardcoded secret key) > > I can get it to work with traditional HMAC, however its way too slow. > Using an optimized HMAC that can take a digest without destroying its > internal state makes things go a lot faster. Fwiw, the folks over on sci.crypt are telling me that its beyond their experience to properly perform crypto analysis on. Perhaps you can help tear it apart!?
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2020-03-03 08:11 +0100 |
| Message-ID | <r3kvvd$n1j$1@dont-email.me> |
| In reply to | #72084 |
On 02/03/2020 22:24, Chris M. Thomasson wrote: > On 3/2/2020 1:21 PM, Chris M. Thomasson wrote: >> On 3/1/2020 1:47 PM, David Brown wrote: >>> Anything in the cryptographic world can be "dangerous". A little >>> knowledge can be a very bad thing here. You are far better off >>> forgetting you ever heard of "Diffie-Hellman" or key exchange - use a >>> good TLS implementation and let people who know what they are doing >>> implement the security. (The authors of such software are not >>> infallible either, so track updates and fixes for the software.) >> >> Fwiw, I have an experimental symmetric cipher. If you get some really >> free time perhaps you can take a look at it: >> >> https://groups.google.com/d/topic/comp.lang.c/a53VxN8cwkY/discussion >> >> http://funwithfractals.atspace.cc/ct_cipher >> >> https://pastebin.com/raw/feUnA3kP >> (C version with hardcoded secret key) >> >> I can get it to work with traditional HMAC, however its way too slow. >> Using an optimized HMAC that can take a digest without destroying its >> internal state makes things go a lot faster. > > Fwiw, the folks over on sci.crypt are telling me that its beyond their > experience to properly perform crypto analysis on. Perhaps you can help > tear it apart!? No, I am don't have the knowledge or experience with cryptography to do an analysis, nor do I have enough maths background (I'm fine with the workings of RSA, but analysis of hashes and encryptions is beyond me).
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2020-03-03 01:31 -0800 |
| Message-ID | <r3l85l$1lr8$5@gioia.aioe.org> |
| In reply to | #72087 |
On 3/2/2020 11:11 PM, David Brown wrote: > On 02/03/2020 22:24, Chris M. Thomasson wrote: >> On 3/2/2020 1:21 PM, Chris M. Thomasson wrote: >>> On 3/1/2020 1:47 PM, David Brown wrote: > >>>> Anything in the cryptographic world can be "dangerous". A little >>>> knowledge can be a very bad thing here. You are far better off >>>> forgetting you ever heard of "Diffie-Hellman" or key exchange - use >>>> a good TLS implementation and let people who know what they are >>>> doing implement the security. (The authors of such software are not >>>> infallible either, so track updates and fixes for the software.) >>> >>> Fwiw, I have an experimental symmetric cipher. If you get some really >>> free time perhaps you can take a look at it: >>> >>> https://groups.google.com/d/topic/comp.lang.c/a53VxN8cwkY/discussion >>> >>> http://funwithfractals.atspace.cc/ct_cipher >>> >>> https://pastebin.com/raw/feUnA3kP >>> (C version with hardcoded secret key) >>> >>> I can get it to work with traditional HMAC, however its way too slow. >>> Using an optimized HMAC that can take a digest without destroying its >>> internal state makes things go a lot faster. >> >> Fwiw, the folks over on sci.crypt are telling me that its beyond their >> experience to properly perform crypto analysis on. Perhaps you can >> help tear it apart!? > > No, I am don't have the knowledge or experience with cryptography to do > an analysis, nor do I have enough maths background (I'm fine with the > workings of RSA, but analysis of hashes and encryptions is beyond me). > Damn! If you happen to know any experts, please show this to them, on your free time. Fwiw, have you tried to run my C code?
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2020-03-03 01:33 -0800 |
| Message-ID | <r3l88q$1lr8$6@gioia.aioe.org> |
| In reply to | #72088 |
On 3/3/2020 1:31 AM, Chris M. Thomasson wrote: > On 3/2/2020 11:11 PM, David Brown wrote: >> On 02/03/2020 22:24, Chris M. Thomasson wrote: >>> On 3/2/2020 1:21 PM, Chris M. Thomasson wrote: >>>> On 3/1/2020 1:47 PM, David Brown wrote: >> >>>>> Anything in the cryptographic world can be "dangerous". A little >>>>> knowledge can be a very bad thing here. You are far better off >>>>> forgetting you ever heard of "Diffie-Hellman" or key exchange - use >>>>> a good TLS implementation and let people who know what they are >>>>> doing implement the security. (The authors of such software are >>>>> not infallible either, so track updates and fixes for the software.) >>>> >>>> Fwiw, I have an experimental symmetric cipher. If you get some >>>> really free time perhaps you can take a look at it: >>>> >>>> https://groups.google.com/d/topic/comp.lang.c/a53VxN8cwkY/discussion >>>> >>>> http://funwithfractals.atspace.cc/ct_cipher >>>> >>>> https://pastebin.com/raw/feUnA3kP >>>> (C version with hardcoded secret key) >>>> >>>> I can get it to work with traditional HMAC, however its way too >>>> slow. Using an optimized HMAC that can take a digest without >>>> destroying its internal state makes things go a lot faster. >>> >>> Fwiw, the folks over on sci.crypt are telling me that its beyond >>> their experience to properly perform crypto analysis on. Perhaps you >>> can help tear it apart!? >> >> No, I am don't have the knowledge or experience with cryptography to >> do an analysis, nor do I have enough maths background (I'm fine with >> the workings of RSA, but analysis of hashes and encryptions is beyond >> me). >> > > Damn! If you happen to know any experts, please show this to them, on > your free time. Fwiw, have you tried to run my C code? Its c99, should compile right up using the following sha2 lib: https://github.com/ogay/hmac and allow you to encrypt and decrypt files using a hardcoded secret key to play with.
[toc] | [prev] | [next] | [standalone]
| From | "daniel...@gmail.com" <danielaparker@gmail.com> |
|---|---|
| Date | 2020-12-08 08:24 -0800 |
| Subject | exception with distinct data members and concatenated what |
| Message-ID | <f591e2c7-c2fe-4562-bc0d-91ac85f215ddn@googlegroups.com> |
| In reply to | #72087 |
How do we implement a robust exception class that has accessors to several string data members, and a what function that returns a concatenation of those strings?
A naive implementation to illustrate the intent is:
class my_error : public std::exception
{
std::string what1_;
std::string what2_;
mutable std::string what_;
my_error(const std::string& what1, const std::string& what2)
: what1_(what1), what2_(what2)
{
}
const std::string& what1() const
{
return what1_;
}
const std::string& what2() const
{
return what2_;
}
const char* what() const noexcept
{
try
{
what_ = what1_ + what2_;
return what_.c_str();
}
catch (...)
{
return what1_.c_str();
}
}
};
Thanks,
Daniel
[toc] | [prev] | [next] | [standalone]
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2020-12-08 10:26 -0800 |
| Subject | Re: exception with distinct data members and concatenated what |
| Message-ID | <e4acb580-ac20-4565-91ea-c84b0c3e6bb3n@googlegroups.com> |
| In reply to | #77191 |
On Tuesday, 8 December 2020 at 18:24:55 UTC+2, daniel...@gmail.com wrote: > How do we implement a robust exception class that has accessors to several string data members, and a what function that returns a concatenation of those strings? The issue with that request is that we avoid exceptions that carry lot of information and make lot of text processing. Exception is information for developer about failure not for text processing or data transporting. Ideally it is cheap and chance of exception from exception is none.
[toc] | [prev] | [next] | [standalone]
Page 4 of 5 — ← Prev page 1 2 3 [4] 5 Next page →
Back to top | Article view | comp.lang.c++
csiph-web