Interesting news about Password protection

[richmond62]

https://forums.livecode.com/viewtopic.php?f=9&t=39054

This seems extremely peculiar:

1. No-one seems to have been aware of this until now.

2. That the development team seem to have been confident this was not possible.
-

SShot 2024-04-19 at 9.57.17.png (35.88 KiB) Viewed 116 times

[FourthWorld]

It's only "news" once it's confirmed. In the meantime it's just speculation.

If the poster had meant the on-disk stack data was not encrypted, I can't reproduce that.

If he was referring to the in-memory representation, Mark Waddingham's reply there explains the situation well:

"Looking at your screenshot it looks like you have stepped through the native code in a debugger - this is always going to expose what an app is doing and everything in memory at every point along the way - regardless of what the original programming language was.

[richmond62]

Well speculation is not always bad; so it is worth considering.

I suppose that we, in the Open Source world, do not really need to worry about Password protection . . .

[FourthWorld]

Their password protection appear to be working as expected.

But all of us benefit from sound practice in handling credentials.

Mark's guidance in that thread reminds us that they included a wide range of industry-standard encryption options for good reason.

[richmond62]

But all of us benefit from sound practice in handling credentials.

Indeed.

But, you did not answer my question.

[tperry2x]

Looking at your screenshot it looks like you have stepped through the native code in a debugger - this is always going to expose what an app is doing and everything in memory at every point along the way - regardless of what the original programming language was.

Not necessarily. This comes back to a previous post regarding memory safe programming languages. Of which there are plenty.

[FourthWorld]

Looking at your screenshot it looks like you have stepped through the native code in a debugger - this is always going to expose what an app is doing and everything in memory at every point along the way - regardless of what the original programming language was.

Not necessarily. This comes back to a previous post regarding memory safe programming languages. Of which there are plenty.

Different set of concerns

The need for encrypted data to become decrypted for use is common to all languages, "memory-safe" or otherwise.

And with all due respect to the ONCD paper, the thin real-world evidence it offers, esp. with regard to importance relative to other quantifiable risks, has not gone unnoticed:

The full report (PDF) is pretty light on technical details, while citing only blog posts by Microsoft and Google as its ‘expert sources’. The claim that memory safety issues are the primary cause of CVEs is not substantiated, or at least ignores the severity of CVEs when looking at the CISA statistics for active exploits. Beyond this call for ‘memory safety’, the report then goes on to effectively call for more testing and validation, while kicking in doors that were opened back in the 1970s already with the Steelman requirements and the High Order Language Working Group (HOLWG) of 1975.

What truly is the impact and factual basis of the ONCD report?

CVE Quality Not Quantity

Perhaps the most vexing of the claims made repeatedly in the ONCD report – as well as the longer, but very similar report by the NSA, CISA and others titled The Case for Memory Safe Roadmaps – is that of memory safety issues being the primary issue. These are claims which seem to always come back to reports by Microsoft and Google, rather than the list of actively exploited CVEs, all of which feature prominently in e.g. the 2023 report on 2022’s top 12 hit list with everyone’s favorite vulnerabilities, such as Log4j (CVE-2021-44228) featuring sloppy input validation, or three CVEs in Microsoft’s Exchange Server, hitting a triple whammy of Common Weakness Enumerations (CWEs).

https://hackaday.com/2024/02/29/the-whi ... d-herring/

[FourthWorld]

But all of us benefit from sound practice in handling credentials.

Indeed.

But, you did not answer my question.

The only question mark in this thread thus far was part of a URL query.

What is your question?

[richmond62]

Oh, you're saying you cannot recognise a question unless it adhere's to some dominie's rules anent questions.

That's unco sair.

So, I'll rephrase it . . .

Do we, in the open source world have to concern ourselves about password protection?

[FourthWorld]

I'd already replied to your observation that password-protected stacks are not a consideration in a fork where that feature doesn't exist.

If you're asking about safe handling of credentials, Mark Waddingham covered that well in this blog post a while back:
https://livecode.com/best-practice-for- ... -security/