Mostly correct. But take into account that basically all regular payments and quite a few others are payee-initiated. The case where you accidentally transfer money to the wrong target has become rare, and rarer still with checksums in the IBAN and a library function for targets in most e-banking software. There are also additional measures. Where I live, the name and address of the target account holder has to match, or the target bank will fail the transfer. And on large or suspicious transfers, they can and usually do ask for confirmation.
As long as you read your statement carefully each month, and are somewhat careful when filling out bank transfer orders, the system works fine.
Ah, sorry. "Checks" went out of fashion here about 15 years ago. You can still use them, but there is a significant fee on that (like $10 or so per instance). Everybody is obliged to accept bank transfers without fee and they are basically free and next-day.
Well, theoretically, you can withdraw money with that, but the account owner can just contest this and then you have to prove you were entitled to that withdrawal and have to pay a rather large fine if you cannot. You also only get the money after a 60 days (I think) waiting period, so this is completely unusable for fraudulent withdrawals.
It is a "big lie" to keep the population docile: Tell them things are much, much better in the US than the rest of the world (which is not true by any halfway sane metric) and they will shut up in fear. Seems to be working well.
The only thing critical contributed by the US was TCP/IP. Sure, for a time the US was custodian of the top-level part of the DNS system, but if they had misbehaved too badly, it would just have been taken away from them forcefully. That would have been rather easy, as the majority of the top-level DNS servers are not located in the US anyways. One level below, the US was never relevant except for some domains. Country-specific domains were always under control of that country. Even.com and the like would have been removed from US control if abused too badly.
So, no, nothing was really given away, because the US never had real power over the Internet.
Will this break regularly scheduled withdrawals for automated billing?
No. First, in Europe, these are _not_ done via credit-card, but via interbank-transfer. Not everybody is stuck in the banking dark-ages like the US. Second, for credit-card based schemes, you authenticate once and then the bank knows these are legit and it works without further authentication.
Now, next step is to do what a full authentication token does (like SecureID): 6 digits and they change every minute. At that point, offline-fraud will basically vanish. Online fraud (man-in-the middle manipulates your purchases) will still be an issue though. For that more sophisticated tokens will be required. They are available and work well, but the banks shy away from the around $20 they cost.
Plus the memory-unsafe premise is BS. There is nothing preventing a programmer from adding their own memory checking in such languages.
And coding carefully in risky places. And using a memory-debugger. And using a code scanner. In the end, it turns out that the language used matters very little for the security of the code, but the skill of the coder is everything.
Very much this. If your programmers are not able to write secure code in C, then do not hire them because they are _incompetent_. They will write insecure code in any other language, it will just not be quite so obvious. And that is a bad thing, because it makes independent review harder. It is quite possible to write grossly insecure code in Java or Rust.
I disagree. This approach is the road to hell, as it drives up cost massively and leads to failing infrastructures that can often not be fixed anymore.
Indeed. And just look at what pretty impressive, secure, stable and fast code is written in C by people that know what they are doing. This whole idiocy about "we need better languages" comes from the same morons that want to teach everybody how to code: They still believe that coding is a menial task that can be done very cheaply, when in actual reality it is among the hardest engineering disciplines known to man.
The focus on programming languages not the issue in my view. It's that serious fields don't do enough to differentiate themselves from casual fields in software.
One reason for that may be that there are not many professional-level coders and that they are expensive. Hiring cheap "casual codes" universally turns out to be very expensive in the long run though.
And that mind-set kills software quality utterly. The tools cannot at this time do anything like you think they can. And there is that second aspect: People are using tools to fill in skills they do not have, but would critically need to understand what they are doing.
No, at this time, you may trust a compiler, but that is about it. Anything more will result in bad code.
Matches my experience. This is exactly what is going on. Most Java "coders" would utterly fail if they needed to code in C and get weeded out. Incidentally, I Java tends to stand in the way of good coders, making the overall effect worse.
Indeed. The reasons are coder skill, or rather lack thereof. Of course, a strong factor is that bad and very bad coders are used in projects because they are cheap. Many of these people have no business writing software that has any level of criticality. Hence while bad coders are the primary cause (and these days most coders are bad), management incompetence that makes them hire bad coders (because "one coder hour" is always the same, right?) is that actual root cause. Bad coders have negative productivity, because afterwards you need to clean up their mess.
Incidentally, all these demented "learn to code" initiatives will make matters worse.
Fascinating. The only thing you are demonstrating here is a very much over-sized ego. And incidentally, you are not the least bit unique. I have seen a lot of broken crypto designs over the years, yours is just one more.
Keep telling that to yourself, eventually you may believe it. Fact of the matter is that it is a complete waste of my time engaging with you. The defects in your design are obvious to anybody with in-depth experience. They are not obvious to you. I cannot fill in your lack of experience.
$1000 buys you about 4 hours of my time. I do not take jobs below 5 days. And I do not take "convince a moron or do not get paid" jobs either.
Sure, I can tell that you are pretty smart, but what makes you a moron is that you think you are much smarter than you actually are. And that makes you fail at recognizing the actual difficulty-levels of things. To use crypto right you have to be pretty smart _and_ you need a lot of experience. One decade is on the low side and that is after at least a full CS master with a crypto-specialization.
Get at the very least 10 year professional practical experience with crypto, then come again and complete your theoretical knowledge, because that is as well lacking. You are so clueless it is painful. Application of cryptography is one of the hardest fields in Computer Science, and amateurs cannot contribute because they lack the basic understanding required. Sure, this sounds arrogant, but there is no helping that because it happens to be true. Would you suggest new ways of doing brain-surgery without being a qualified brain-surgeon? Of course not. But for some reason I still do not understand, when it comes to crypto, every amateur thinks they can tell the professionals how it is done. And that _is_ arrogance on your part.
And no, I am not going to try to fill you in on the things you would understand here if you were an expert. You are not even going to be able to understand what I am talking about.
I just had a second look and realized you do not even seem to have heard about _iterated_ hashing, which is the standard for now > 40 years (UNIX-passwords started it, I think, and at that time they did not even have proper crypto-hashes). And that is already an outdated thing as it is considered not secure enough in an age where graphics-cards get ever more powerful. I am sure you have not heard of things like Argon2 (that fix iterated hashing) either.
So, seriously, how incompetent can you get? Talk about an extreme left-side Dunning-Kruger sample.
Hahahaha, funny. Offering a pittance (this will not even buy one of my days as an expert) and no assurance you will pay because, surprise!, you are the judge of what qualifies as proof and you already have demonstrated pretty bad judgment.
Slashdot Mirror
Mostly correct. But take into account that basically all regular payments and quite a few others are payee-initiated. The case where you accidentally transfer money to the wrong target has become rare, and rarer still with checksums in the IBAN and a library function for targets in most e-banking software. There are also additional measures. Where I live, the name and address of the target account holder has to match, or the target bank will fail the transfer. And on large or suspicious transfers, they can and usually do ask for confirmation.
As long as you read your statement carefully each month, and are somewhat careful when filling out bank transfer orders, the system works fine.
Ah, sorry. "Checks" went out of fashion here about 15 years ago. You can still use them, but there is a significant fee on that (like $10 or so per instance). Everybody is obliged to accept bank transfers without fee and they are basically free and next-day.
You have a "checking account"? Nice. These went out of fashion about 15 years ago here. I stand by my statement: Banking dark-ages.
Well, theoretically, you can withdraw money with that, but the account owner can just contest this and then you have to prove you were entitled to that withdrawal and have to pay a rather large fine if you cannot. You also only get the money after a 60 days (I think) waiting period, so this is completely unusable for fraudulent withdrawals.
It is a "big lie" to keep the population docile: Tell them things are much, much better in the US than the rest of the world (which is not true by any halfway sane metric) and they will shut up in fear. Seems to be working well.
Sounds like somebody is pushing an utterly stupid and destructive idea to earn a lot of money.
The only thing critical contributed by the US was TCP/IP. Sure, for a time the US was custodian of the top-level part of the DNS system, but if they had misbehaved too badly, it would just have been taken away from them forcefully. That would have been rather easy, as the majority of the top-level DNS servers are not located in the US anyways. One level below, the US was never relevant except for some domains. Country-specific domains were always under control of that country. Even .com and the like would have been removed from US control if abused too badly.
So, no, nothing was really given away, because the US never had real power over the Internet.
Will this break regularly scheduled withdrawals for automated billing?
No. First, in Europe, these are _not_ done via credit-card, but via interbank-transfer. Not everybody is stuck in the banking dark-ages like the US. Second, for credit-card based schemes, you authenticate once and then the bank knows these are legit and it works without further authentication.
Now, next step is to do what a full authentication token does (like SecureID): 6 digits and they change every minute. At that point, offline-fraud will basically vanish. Online fraud (man-in-the middle manipulates your purchases) will still be an issue though. For that more sophisticated tokens will be required. They are available and work well, but the banks shy away from the around $20 they cost.
Plus the memory-unsafe premise is BS. There is nothing preventing a programmer from adding their own memory checking in such languages.
And coding carefully in risky places. And using a memory-debugger. And using a code scanner. In the end, it turns out that the language used matters very little for the security of the code, but the skill of the coder is everything.
Very much this. If your programmers are not able to write secure code in C, then do not hire them because they are _incompetent_. They will write insecure code in any other language, it will just not be quite so obvious. And that is a bad thing, because it makes independent review harder. It is quite possible to write grossly insecure code in Java or Rust.
I disagree. This approach is the road to hell, as it drives up cost massively and leads to failing infrastructures that can often not be fixed anymore.
Indeed. And just look at what pretty impressive, secure, stable and fast code is written in C by people that know what they are doing. This whole idiocy about "we need better languages" comes from the same morons that want to teach everybody how to code: They still believe that coding is a menial task that can be done very cheaply, when in actual reality it is among the hardest engineering disciplines known to man.
The focus on programming languages not the issue in my view. It's that serious fields don't do enough to differentiate themselves from casual fields in software.
One reason for that may be that there are not many professional-level coders and that they are expensive. Hiring cheap "casual codes" universally turns out to be very expensive in the long run though.
And that mind-set kills software quality utterly. The tools cannot at this time do anything like you think they can. And there is that second aspect: People are using tools to fill in skills they do not have, but would critically need to understand what they are doing.
No, at this time, you may trust a compiler, but that is about it. Anything more will result in bad code.
To a good craftsman, C is a good tool. To an incompetent, it is not.
Matches my experience. This is exactly what is going on. Most Java "coders" would utterly fail if they needed to code in C and get weeded out. Incidentally, I Java tends to stand in the way of good coders, making the overall effect worse.
Indeed. The reasons are coder skill, or rather lack thereof. Of course, a strong factor is that bad and very bad coders are used in projects because they are cheap. Many of these people have no business writing software that has any level of criticality. Hence while bad coders are the primary cause (and these days most coders are bad), management incompetence that makes them hire bad coders (because "one coder hour" is always the same, right?) is that actual root cause. Bad coders have negative productivity, because afterwards you need to clean up their mess.
Incidentally, all these demented "learn to code" initiatives will make matters worse.
Fascinating. The only thing you are demonstrating here is a very much over-sized ego. And incidentally, you are not the least bit unique. I have seen a lot of broken crypto designs over the years, yours is just one more.
Keep telling that to yourself, eventually you may believe it. Fact of the matter is that it is a complete waste of my time engaging with you. The defects in your design are obvious to anybody with in-depth experience. They are not obvious to you. I cannot fill in your lack of experience.
$1000 buys you about 4 hours of my time. I do not take jobs below 5 days. And I do not take "convince a moron or do not get paid" jobs either.
Sure, I can tell that you are pretty smart, but what makes you a moron is that you think you are much smarter than you actually are. And that makes you fail at recognizing the actual difficulty-levels of things. To use crypto right you have to be pretty smart _and_ you need a lot of experience. One decade is on the low side and that is after at least a full CS master with a crypto-specialization.
Get at the very least 10 year professional practical experience with crypto, then come again and complete your theoretical knowledge, because that is as well lacking. You are so clueless it is painful. Application of cryptography is one of the hardest fields in Computer Science, and amateurs cannot contribute because they lack the basic understanding required. Sure, this sounds arrogant, but there is no helping that because it happens to be true. Would you suggest new ways of doing brain-surgery without being a qualified brain-surgeon? Of course not. But for some reason I still do not understand, when it comes to crypto, every amateur thinks they can tell the professionals how it is done. And that _is_ arrogance on your part.
And no, I am not going to try to fill you in on the things you would understand here if you were an expert. You are not even going to be able to understand what I am talking about.
Well, yes. Of course, if many people do that, everything goes to crap in the end, but that seems to be the current trend.
I just had a second look and realized you do not even seem to have heard about _iterated_ hashing, which is the standard for now > 40 years (UNIX-passwords started it, I think, and at that time they did not even have proper crypto-hashes). And that is already an outdated thing as it is considered not secure enough in an age where graphics-cards get ever more powerful. I am sure you have not heard of things like Argon2 (that fix iterated hashing) either.
So, seriously, how incompetent can you get? Talk about an extreme left-side Dunning-Kruger sample.
And then you want to change all browsers...
Hahahaha, funny. Offering a pittance (this will not even buy one of my days as an expert) and no assurance you will pay because, surprise!, you are the judge of what qualifies as proof and you already have demonstrated pretty bad judgment.