3 ms·

Security is built out of generic programming concepts, rate limiting, input validation, authorization, encryption, etc. When you apply these programming concep

by ojr 10mo ago

Security is built out of generic programming concepts, rate limiting, input validation, authorization, encryption, etc. When you apply these programming concepts like atomic operations to something that control moneys it becomes security engineering. Atomicity is literally the foundation of preventing double spending in a financial system. If people can spend bitcoin twice the price crashes to $0. Understanding atomicity is very important for cybersecurity/integrity of the system. With more programming experience you’ll understand the mapping of studying crypto smart contract vulnerabilities and applying lessons to a non-blockchain database. Programmers like you make me never feel threaten that my apps would be cloned, too many gaps in knowledge of system design.

TZubiri 10mo ago
>Security is built out of generic programming concepts, rate limiting, input validation, authorization, encryption, etc. With the exception of rate limiting, those are indeed security techniques. The generic programming concepts, like Atomicity and rate limiting are generic because, although maybe relevant to security, they would exist even without malicious actors. Atomicity for example is used on disk and database writes to avoid ilegal states in the case of power outages or crashes. Rate limiting on the other hand would still exist without malicious actors, to distribute limited resources when demand exceeds supply. And it often is used in the context of paid apis with different pricings based on different limits. So in essence some concepts strictly exist to protect against malicious actors, while others protect against random conditions or good faith actors. >With more programming experience you’ll understand the mapping of studying crypto smart contract vulnerabilities and applying lessons to a non-blockchain database. If I'm not mistaken you started learning about programming and security very recently (which is why you can't distinguish between the two) and mostly through chatgpt? Might pay off to be less cocky, or maybe it's a good strategy so that veterans correct you, either way, all the best.
- ojr 10mo ago
  > So in essence some concepts strictly exist to protect against malicious actors, while others protect against random conditions or good faith actors. Guess what both fall under umbrella of cybersecurity. Please consult with your favorite LLM to break it down to you. I can't continue having a conversation with a beginner posturing as a security veteran, who thinks rate limiting and having atomic operations in things that involve money is not cybersecurity. blockchain smart contracts I wrote 8 years ago: https://github.com/Slidebits/ethereum-smart-contracts https://github.com/Slidebits/ethereum-smart-contracts iOS app, that "good faith" hackers try to constantly abuse through what you call "random conditions": https://apps.apple.com/us/app/slidebits-ai-playground/id1138731130 https://apps.apple.com/us/app/slidebits-ai-playground/id1138... Maybe you can share some of things that form your opinion?

by ojr 10mo ago

TZubiri 10mo ago

>Security is built out of generic programming concepts, rate limiting, input validation, authorization, encryption, etc. With the exception of rate limiting, those are indeed security techniques. The generic programming concepts, like Atomicity and rate limiting are generic because, although maybe relevant to security, they would exist even without malicious actors. Atomicity for example is used on disk and database writes to avoid ilegal states in the case of power outages or crashes. Rate limiting on the other hand would still exist without malicious actors, to distribute limited resources when demand exceeds supply. And it often is used in the context of paid apis with different pricings based on different limits. So in essence some concepts strictly exist to protect against malicious actors, while others protect against random conditions or good faith actors. >With more programming experience you’ll understand the mapping of studying crypto smart contract vulnerabilities and applying lessons to a non-blockchain database. If I'm not mistaken you started learning about programming and security very recently (which is why you can't distinguish between the two) and mostly through chatgpt? Might pay off to be less cocky, or maybe it's a good strategy so that veterans correct you, either way, all the best.

ojr 10mo ago
> So in essence some concepts strictly exist to protect against malicious actors, while others protect against random conditions or good faith actors. Guess what both fall under umbrella of cybersecurity. Please consult with your favorite LLM to break it down to you. I can't continue having a conversation with a beginner posturing as a security veteran, who thinks rate limiting and having atomic operations in things that involve money is not cybersecurity. blockchain smart contracts I wrote 8 years ago: https://github.com/Slidebits/ethereum-smart-contracts https://github.com/Slidebits/ethereum-smart-contracts iOS app, that "good faith" hackers try to constantly abuse through what you call "random conditions": https://apps.apple.com/us/app/slidebits-ai-playground/id1138731130 https://apps.apple.com/us/app/slidebits-ai-playground/id1138... Maybe you can share some of things that form your opinion?