On 4/28/2019 11:31 AM, Konstantin Tokarev wrote:
28.04.2019, 19:15, "Roland Hughes" <rol...@logikalsolutions.com>:
If you are worried about a sensitive value being memory dumped because
of a completely insecure scripted language, then don't do it there.
If some data is copied to memory it can be dumped from there, no matter
what language are you using. There are no "secure" and "insecure" languages
in this regard.
Sure there are.
https://dwheeler.com/secure-programs/Secure-Programs-HOWTO/protect-secrets.html
https://www.oreilly.com/library/view/secure-programming-cookbook/0596003943/ch01s09.html
Most importantly, by placing all of the sensitive data used only for
debug in C++ class methods bounded by #ifdef DEBUG statements, in a
production release the copy will never happen.
The scarier architectural problem with the original post is the
console.log() call is calling something to convert a password to "free
text" rather than dumping a hashed/encrypted version. Most production
applications never bother with this. They compare a hashed/encrypted
version of the entered password with the hashed/encrypted version stored
on disk.
Scripted languages are inherently insecure. With QML and JavaScript you
end up with stuff like this in your elf binary.
DefaultButton {
id: helpButton
text: qsTr("Help")
iconSource: helpButton.pressed ? "/Images/help_pressed.png" :
"/Images/NewButtonIcons/help_notpressed.png"
iconSizeX: 17
iconSizeY: 24
onClicked: {
popupHelpInfo.open()
popupHelpInfo.forceActiveFocus()
}
I found that in a few seconds with Eclipse. Any number of "text" editors
will let you open and view binaries. The amount of code and logic
actually exposed to anyone willing to edit a copy of the file is
immense. Not so with compiled C/C++ or even COBOL for that matter. If
you are really worried about things like "Password" being found you have
multiple options.
1) Under Qt use tr("1234") and always have a translation file, even for
your native language.
2) Under any compiled language build the string programatically from Hex
strings. FWIW, the Hex values for "Password" are 50 61 73 73 77 6F 72 64
With a scripted language there is little you can do to avoid exposing
your code. Yes, there is an option to "precompile" QML but it comes with
significant limitations.
https://doc.qt.io/qt-5/qtquick-deployment.html
The most significant of which is being tightly bound to the version of
QML compiled against. For an embedded system where you control the
universe this could be acceptable. For an app which anyone can download
and run it is not. If you developed under 5.2 and didn't use anything
which disappeared in 5.12 you still want the user to be able to run your
app. The inverse is true as well. Just because you used 5.12 doesn't
mean you used something which only existed in 5.12.
Under various operating systems (OpenVMS in particular) one can tell the
compiler for the language of choice to place all string constants within
a single PSECT or a series of them. In your linker options the named
PSECT(s) can be flagged with an attribute which excludes them from dump
utilities. These principals have been around since the 1980s when I
started programming commercially on big-boy systems. Didn't matter if we
were working in COBOL, FORTRAN or BASIC, we always had linker option
files to flag string constant PSECTs as nodump. Even if the midrange or
mainframe was air-gapped from the world we still did this. Back then we
were only worried about dial-up access, the Internet did not exist in
any meaningful way.
With a scripted language you cannot do this. You are at the mercy of the
engine.
It would be interesting to see just how much text survives in
pre-compiled QML. I would imagine it is a lot. If the QML engine is
OpenSource then it isn't a difficult task for someone intent on gaining
passwords via a dump or cache file on disk to find the text "Password"
and decompile everything around it. They can't get back to the original
source, but they can get close enough.
Basically, if your application must be secure you cannot use a scripted
language.
--
Roland Hughes, President
Logikal Solutions
(630) 205-1593
http://www.theminimumyouneedtoknow.com
http://www.infiniteexposure.net
http://www.johnsmith-book.com
http://www.logikalblog.com
http://www.interestingauthors.com/blog
http://lesedi.us
_______________________________________________
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
