|
David A. Gray wrote: In any case, I try to maintain a broad, technology-agnostic viewpoint. It is from that viewpoint that I believe that Hungarian notation still has merit.
Dim iCurDate As String Happened too often in brownfields.
"Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. Code for readability." (From some manual, and it is good advice)
David A. Gray wrote: my chief design goal was to extend the conventions to dynamic languages (e. g., Perl, JavaScript, PHP) that don't enforce variable typing
I dislike all weak languages. Makes weak programs that are based on an on error resume next philosophy.
David A. Gray wrote: ensuring consistency of names across entire code bases, regardless of implementation language
That sounds like an advantage, but why does it need to be consistent in different languages? Delphi has some weird string-types, does it make sense to unify that with JavaScript? And what do I gain by doing so?
David A. Gray wrote: Nevertheless, I retain them for private entities, especially in "system" or "utility" libraries.
If you can be consistent, then it would not be much of a problem; but if the prefixes are there, I expect them to be correct.
So, I would not oppose the use of it, especially not if one is so accustomed to doing it so that it becomes a habit and goes nearly automatically.
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
Eddy Vluggen wrote: I dislike all weak languages. Makes weak programs that are based on an on error resume next philosophy
I don't either, but they are here to stay. As for the "weak" languages being based on the "on error resume next" philosophy, this was once true, but modern ECMAScript, PHP, and Python support rich try/catch/finally blocks, custom exceptions, and pretty much anything else that was once reserved for C, C++, C#, and the like.
Eddy Vluggen wrote: So, I would not oppose the use of it, especially not if one is so accustomed to doing it so that it becomes a habit and goes nearly automatically.
I've been using them for so many years that they are automatic. Indeed, I have to consciously elect to refrain from using them.
David A. Gray
Delivering Solutions for the Ages, One Problem at a Time
Interpreting the Fundamental Principle of Tabular Reporting
|
|
|
|
|
"Hungarian Notation" can be traced to a time when some languages would only support "very short" variable / db names (e.g. 10 chars); and / or case-insensitive.
Now, we are encouraged to use meaningful names (with limits rarely less than 256 chars) that are a lot more expressive than simply int vs double (which OFTEN changes), etc.
"(I) am amazed to see myself here rather than there ... now rather than then".
― Blaise Pascal
|
|
|
|
|
Gerry Schmitz wrote: Now, we are encouraged to use meaningful names (with limits rarely less than 256 chars) that are a lot more expressive than simply int vs double (which OFTEN changes), etc.
That is, of course, a risk that you take when you use Hungarian prefixes.
- However, when you change the type of an internal variable, renaming it is straightforward.
- OTOH, when you change the type of a parameter, you break the interface, and the new interface must be documented and published as such. In that case, renaming the argument is not only acceptable, but desirable, since it exposes references to the argument as diagnostic messages.
Nobody is forcing you to use Hungarian notation. Only a portion of these conventions relies upon them, and the remaining conventions stand on their own.
David A. Gray
Delivering Solutions for the Ages, One Problem at a Time
Interpreting the Fundamental Principle of Tabular Reporting
|
|
|
|
|
I used to use it; and no one "forced" me.
Me, AND MS, have concluded subsequently that the notation is "passe".
("Renaming", in an established app, is a LAST resort IMO. And a "parameter" is not the same as an "interface"; and doesn't apply in this context).
"(I) am amazed to see myself here rather than there ... now rather than then".
― Blaise Pascal
modified 3-Jun-18 12:28pm.
|
|
|
|
|
Gerry Schmitz wrote: Me, AND MS, have concluded subsequently that the notation is "passe".
Neither of which makes it so.
Gerry Schmitz wrote: ("Renaming", in an established app, is a LAST resort IMO. And a "parameter" is not the same as an "interface"; and doesn't apply in this context).
As is usually the case, renaming for no particular reason is bad practice. Nevertheless, renaming a private variable that has function scope is neither unusual, nor necessarily a last resort. since designing software is a thinking man's game, there is ample room for thinking things through, and renaming variables judiciously.
In the context in which I used the term, parameter is a key element of an interface. In this context, interface is the combination of the signature (order and types of parameters) and the return type of a function. No thanks to IntelliSense, the parameter names displayed by Visual Studio reflect the internally defined names of the parameters of the selected method. Hence, their names are part of the interface definition, whether we like it or not. This is the only reason by which I can justify abandoning Hungarian prefixes for them. Even then, I think doing so is questionable because, in so doing, you throw away some very important metadata.
David A. Gray
Delivering Solutions for the Ages, One Problem at a Time
Interpreting the Fundamental Principle of Tabular Reporting
|
|
|
|
|
I am developing a simple web blog. As a DB system, I want to use XML.
How doable is it?
How proper/suitable is it?
Why XML?
1-) Just for the sake of it. I mean I never saw a blog based on XML.
|
|
|
|
|
Rakanoth wrote: How doable is it?
Very; a matter of loading the data in ASP and displaying it. Online editing might take a bit more.
Rakanoth wrote: How proper/suitable is it?
XML works best as a data-exchange format, not as a storage-engine. As long as your not doing complex queries on your data things should behave well.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
Any tips to apply HATEOAS into CQRS .Net Core web service which Read and Command stakes are separately deployed into 2 different web apps ?
|
|
|
|
|
Dear experts
I need to secure an application to prevent from unauthorized use. I like to do this a simple as possible. This in regard to me to program it but also for the customers to make the handling as easy as possible for them.
At this moment, I try to prevent from creating something like a licensefile. My idea so far is:
User
The user gets displayed a so called SystemID: XXXX-XXXX-XXXX-XXXX
The System ID is generated by MD5 Hashing of e.g. [CPU ID, MOTHER BOARD ID, etc] and Base36 encoded.
Licensor
From the above SystemID a signature will be determined using a Private Key.
From this signature again a MD5 Hash will be calculated and encoded also in Base36.
Finally this will result in the activation key: YYYY-YYYY-YYYY-YYYY
This activation key will be used then (PUBLIC_KEY, ...) to verify the activation
My strange question
Is the above more or less secure? I know it is hard to give an answer, this in regard that I even don't know a scale to measure "secure".
Maybe the question should be more: Is it easy to hack this activation procedure?
For me it looks nearly uncrackable (or let's say it would be very difficult). But this also only because I have no affinity for these crypt stuff 
Remarks
- The application is Native W32 programmed in c++
- For me personally, hiding the final something like bool IsActivated() is at least same difficult/critical
- Base36: Looks like I Need to think about this again.... Base36_Enc(Max(uint_32)) will be "1z141z3"
Thank you very much in advance for your comments.
It does not solve my Problem, but it answers my question
modified 19-Jan-21 21:04pm.
|
|
|
|
|
0x01AA wrote: For me it looks nearly uncrackable
If it runs on my computer I can always hack it.
Other than that I suggest googling.
|
|
|
|
|
I googled very much believe me! Now please tell me how to prove whter the above is good or bad...
[Edit]
And yes the down vote is from my side. I think you should not earn "answer" Points for your message before.
It does not solve my Problem, but it answers my question
modified 19-Jan-21 21:04pm.
|
|
|
|
|
The upvote is mine. There is no way to prove how good it is; and with the amount of cracked games out there, you have little chance of outperforming those teams.
The good news is that those games gather a lot of attention, and most business-apps do not.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
Eddy Vluggen wrote: The upvote is mine.
I don't see an upvote. Do you see one?
|
|
|
|
|
Randor wrote: I don't see an upvote. Do you see one?
Yes, I do. It's visible once you vote and not shown as expected. Repeat your vote to see the current value; "You voted 5. Rating is now 3.67/5 (3 votes)"
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
I corrected my vote. This because I recognized that I completely misinterpreted your message on my first read.
I read tons of articles... the more I read the more confused/unsafe I am. In case you are safe in this field, can you help me?
Is there a difference related to "hackable" between this two ways of signing a message:
1.) Variant I.
a.) Hashing a text
b.) Encrypt Hash with private key
2.) Variant II.
a.) Encrypt text
b.) Hashing the encrypted text
Thank you very much in advance.
It does not solve my Problem, but it answers my question
modified 19-Jan-21 21:04pm.
|
|
|
|
|
0x01AA wrote: Is there a difference related to "hackable" between this two ways of signing a message:
In terms of hacking, I wouldn't target a hash-algo, I'd target the assembly that does the check in your application.
In terms of usability; you can calculate a hash, and recalculate it to verify that the target is not changed. If you encrypt it after hashing, then I no langer can recalculate the hash, and I can no longer verify that the content hasn't changed.
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
Thank you for your Feedback.
Quote: I'd target the assembly that does the check in your application
I agree completely. That is the other part which makes me headache, because I think it ends always more or less with a final something like if(lic)
Quote: If you encrypt it after hashing, then I no langer can recalculate the hash
I don't agree. If I encrypt the hash with my private key, the application can still check the encrypted hash with it's public key.
It does not solve my Problem, but it answers my question
modified 19-Jan-21 21:04pm.
|
|
|
|
|
0x01AA wrote: I don't agree. If I encrypt the hash with my private key, the application can still check the encrypted hash with it's public key.
Signing is a bit more complex than hashing and encrypting. Yes, your app can decrypt the hashcode and verify, but what's the use? Most Linux-apps simply state the MD5 publicly, just because it doesn't need to be a secret 
0x01AA wrote: I agree completely. That is the other part which makes me headache, because I think it ends always more or less with a final something like if(lic)
You're thinking in terms of security. Think of the worst thing you could encounter when trying to break it.
Imagine a non-descript class, initialized with some weird defaults. Next, pick a random "if" in your application (one that breaks the app if done wrong) and add a check for the weird default of the non-descript class. Multiply ints for positioning controls by a random letter from Application.ProductName, and divide by a similar constant grabbed elsewhere. Consider it obfuscation of that single "if (lic)" statement. Check the Weird & Wonderfull forum for some nice pieces of code with weird side-effects or hard to read statements. Make it look like a bug, not security!
You will hate me for the suggestion if you have to do some maintenance though 
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
Thank you very much again.
Quote: You will hate me for the suggestion if you have to do some maintenance though
I did similar in the past (before about 20 years) where I used an Array of function pointers, "bad" ones and "good" ones. After some years I had to maintain it and I hated myself for this code 
The big difference this time is
a.) In the past I only needed to prevent from unauthorized use of our application. In fact I could hide the decision also "by time"; I mean it was no problem to check legal use and stop the application later after about (random) 1...10 Minutes.
b.) This time I need to prevent from unauthorized use of protected data. So I need to take the decision immediately. But as you mentioned, obfuscating the decision is more or less the only way.
It does not solve my Problem, but it answers my question
modified 19-Jan-21 21:04pm.
|
|
|
|
|
0x01AA wrote: I Need to prevent from illegal
There are cost-effective ways to do so, and we do have articles on the subject. There's no way to get a 100% guarantee.
If it "really" needs to be protected, don't distribute it - host it
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
0x01AA wrote: Is there a difference related to "hackable" between this two ways of signing a message:
That is the wrong question.
It isn't whether a method is secure or not.
The real question is what does a bad actor want to do? What is their objective?
So for example in terms of email do they want to inject a false message in the stream or do they just want to see the emails. I would suspect most of the time it is the latter not the former. And so all they need is access to the client machine and some way to capture the content that the client machine will display. Or even using the client machine to determine the sender's machine and hacking that machine instead.
A couple of years ago a security firm, a firm whose entire business model was based on making other companies more secure, was hacked because one of the top level execs responded to an email phishing attempt that was generated internally from another hacked email account. Certainly in that case even if both accounts were encrypted and signed it wouldn't have mattered because the the bad actors had already gotten access to the one email account and then it was lax process (not technology) that allowed the break.
|
|
|
|
|
Hi,
The best article I've ever seen here on codeproject for generating product activation keys is here:
Product Activation Based on RSA Signatures[^]
It's using elliptic curve cryptography and supports tag-bits if you want to fingerprint the hardware. Even here in 2018 the technique he is using is very secure. It's not much different than what's being used to generate your operating system activation keys. In fact it's superior to the Windows product key generation algorithm if you embed the hardware fingerprint.
Best Wishes,
-David Delaune
Edit:
Sorry, I gave you the wrong article. The article I am referring to is here:
Product Keys Based on Elliptic Curve Cryptography[^]
I noticed a few years ago that it became marked as deleted. Not sure why... it's an extremely good article.
modified 12-May-18 18:51pm.
|
|
|
|
|
Thank you very much for this.
It does not solve my Problem, but it answers my question
modified 19-Jan-21 21:04pm.
|
|
|
|
|
Hi,
Beware that the algorithm that is being used in ECB[^] to generate curves appears to have changed. If you look at the algorithm instructions in IDA Pro/Hex-Rays[^] it's completely different from the older builds from a decade ago. I am not skilled enough in mathematics and crypto to understand why the changes I am seeing have been made. Also I don't see a Windows build on his site anymore.
You can skip the steps for generating curves and just use one of the NIST recommended FIPS 186-4 curves[^]. The curve properties are near the bottom of the document.
Best Wishes,
-David Delaune
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
