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 | 7 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 5 of 5 — ← Prev page 1 2 3 4 [5]
| From | "daniel...@gmail.com" <danielaparker@gmail.com> |
|---|---|
| Date | 2020-12-08 11:00 -0800 |
| Subject | Re: exception with distinct data members and concatenated what |
| Message-ID | <f192fae2-5ae7-49a6-b4a6-00842248a0e0n@googlegroups.com> |
| In reply to | #77194 |
On Tuesday, December 8, 2020 at 1:26:43 PM UTC-5, Öö Tiib wrote:
> 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.
I don't think that's entirely correct. Software that relies on exceptions for
handling errors may have no other channel for communicating
information that must end up in messages to users, for example,
the line and column number where a parsing error occurred, in
addition to a description of the parsing violation.
Even boost sometimes does text processing when constructing
exception messages, for example (snipping the irrelevant bits),
class bad_virtual_result_cast :
public std::bad_cast, public boost::contract::exception {
public:
explicit bad_virtual_result_cast(char const* from_type_name,
char const* to_type_name)
{
std::ostringstream text;
text << "incompatible contracted virtual function result type "
<< "conversion from '" << from_type_name << "' to '"
<< to_type_name << "'" ;
what_ = text.str();
}
virtual char const* what() const BOOST_NOEXCEPT_OR_NOTHROW
{
return what_.c_str();
}
private:
std::string what_;
};
Daniel
[toc] | [prev] | [next] | [standalone]
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2020-12-08 13:17 -0800 |
| Subject | Re: exception with distinct data members and concatenated what |
| Message-ID | <72605b6b-65b9-4510-96ee-08ff22372562n@googlegroups.com> |
| In reply to | #77195 |
On Tuesday, 8 December 2020 at 21:01:12 UTC+2, daniel...@gmail.com wrote: > On Tuesday, December 8, 2020 at 1:26:43 PM UTC-5, Öö Tiib wrote: > > 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. > I don't think that's entirely correct. Software that relies on exceptions for > handling errors may have no other channel for communicating > information that must end up in messages to users, for example, > the line and column number where a parsing error occurred, in > addition to a description of the parsing violation. It is unlikely that I want to show exception texts to user ever as error handling, error reporting, user interface and debugging are different concerns. Conflating those together results with all being weak as exceptions are not silver bullets. Exceptions should be used for handling exceptional situations. Exceptional means that those happen rarely. Rarely happening situations are less tested. More complexity will add more chances of defects into those places. Adding more debugging need is counter- intuitive. User interface must be clear and might be needed to be translated. > > Even boost sometimes does text processing when constructing > exception messages, for example (snipping the irrelevant bits), Boost is not always good example of best practices. Some things are well made. Some are over-complicated and then either not competitive or compile slowly because of too lot of meta-programming. Your example was exception about misuse of some boost library feature by programmer. Only programmer can fix that problem, and so it is of no much value to catch site nor to user.
[toc] | [prev] | [next] | [standalone]
| From | Paavo Helde <myfirstname@osa.pri.ee> |
|---|---|
| Date | 2020-12-08 22:13 +0200 |
| Subject | Re: exception with distinct data members and concatenated what |
| Message-ID | <rqomoo$7bu$1@dont-email.me> |
| In reply to | #77191 |
08.12.2020 18:24 daniel...@gmail.com kirjutas:
> 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?
I understand you worry about memory exhaustion while constructing an
error message. This question is mostly theoretical. If the machine is so
out of memory that it cannot construct a single error message even after
stack unwinding, then you have got much more serious troubles than
trying to preserve your error message text. Most likely your error
handler would not be able to process the long error message properly anyway.
So it does not really matter what you return. Considering the memory is
fully exhausted, it makes some sense to return a very short string,
increasing the chances the error handler is able to cope with it. E.g.:
try {
// ...
} catch(...) {
return "No memory";
}
With some kind of software, it might be even preferable to kill the
program on spot if memory appears to be fully exhausted. But this is
probably better done in the out-of-memory handler.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2020-02-28 23:38 -0800 |
| Message-ID | <r3d4ds$816$1@gioia.aioe.org> |
| In reply to | #72060 |
On 2/28/2020 10:51 PM, 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. Exactly. This is why its good to try to setup a temporary secure channel, just to send ciphertext to the server. >> >>> >>> /Flibble >>> >> > >
[toc] | [prev] | [next] | [standalone]
| From | Melzzzzz <Melzzzzz@zzzzz.com> |
|---|---|
| Date | 2020-02-29 06:50 +0000 |
| Message-ID | <sQn6G.1466759$GFe.1117886@fx12.am4> |
| In reply to | #72057 |
On 2020-02-29, Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> 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. Hash or ciphertext? Hash is same as sending it in 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 | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2020-02-28 23:32 -0800 |
| Message-ID | <r3d41u$5i2$1@gioia.aioe.org> |
| In reply to | #72059 |
On 2/28/2020 10:50 PM, Melzzzzz wrote: > On 2020-02-29, Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> 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. > > Hash or ciphertext? Hash is same as sending it in plain text. We want a ciphertext to be sent across the wire. We can use async crypto to get a shared key, then encrypt using a symmetric cipher. > >> >> /Flibble >> > >
[toc] | [prev] | [next] | [standalone]
| From | woodbrian77@gmail.com |
|---|---|
| Date | 2020-08-04 18:28 -0700 |
| Message-ID | <8cefe8ce-fc23-41ad-a9e9-e3688df9c066o@googlegroups.com> |
| In reply to | #69492 |
On Wednesday, October 30, 2019 at 11:58:27 AM UTC-5, woodb...@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. > > > Brian > Ebenezer Enterprise - America isn't great because America is powerful. > America is powerful because America is great. Ben Shapiro at dailywire.com https://github.com/Ebenezer-group/onwards/commit/01e81ab1c93cc60ad3754dbbfe64ed4fb0864cfd
[toc] | [prev] | [standalone]
Page 5 of 5 — ← Prev page 1 2 3 4 [5]
Back to top | Article view | comp.lang.c++
csiph-web