
How to Read UTF-8 Passwords on the Windows Console - todsacerdoti
https://nullprogram.com/blog/2020/05/04/
======
hprotagonist
Tangentially related:
[https://apple.stackexchange.com/q/202143](https://apple.stackexchange.com/q/202143)

“I included emoji in my password and now I can’t log on to Yosemite”

------
acqq
Casually looking, it seems he misses to use SecureZeroMemory?

[https://docs.microsoft.com/en-us/previous-
versions/windows/d...](https://docs.microsoft.com/en-us/previous-
versions/windows/desktop/legacy/aa366877\(v=vs.85\))

Also note:

"Use this function instead of ZeroMemory when you want to ensure that your
data will be overwritten promptly, as _some C++ compilers can optimize a call
to ZeroMemory by removing it entirely._ "

Managing passwords is tricky.

Edit: answering: "I don't see the post talking about zeroing memory
anywhere?": Exactly. But it uses "free".

    
    
        free(wbuf);
    

It is freed without being zeroed. Without demonstrating freeing, and without
having the "clean up" part it would not matter. With it, and the given context
(writing about using APIs to handle passwords), it does matter, and you should
care too. Even more so if you a) aren't aware of the possibility of the
compiler optimizations b) haven't even thought about the possible "leaking"
issues.

~~~
yrro
It's probably also a good idea to call VirtualLock so that the passwotrd is
guaranteed to never be written to virtual memory.

~~~
acqq
Right, at least, avoiding C allocation and deallocation functions can surely
give one more control over the used memory segment. And I am not aware of any
discussion of the positive or negative aspects of CryptMemAlloc and
CryptMemFree.

~~~
yrro
Does the memory managed by these functions have any special properties? The
docs don't mention any, other than that these functions are used by Crypt*
functions that return buffers (i.e., client sshould free returned buffers with
CryptMemFree).

~~~
acqq
> Does the memory managed by these functions have any special properties?

That's what I'd like to read too. It's surely possible to figure that out.
Obviously, nothing special is promised by the description of the functions.

I know that some people, long ago, even wrote their own kernel drivers to make
sure some part of the memory won't end in the virtual memory on the disk. They
didn't think VirtualLock gives that guarantee.

------
ChrisSD
tl;dr: The Windows console uses UTF-16. You need to convert to/from UTF-16 if
you want to use another encoding elsewhere in your program.

------
barbegal
And this is why the bank says you can only create a password with alphanumeric
characters. Despite the huge advances of UTF-8 adoption there are still large
numbers of systems out there where you can't reliably use anything other than
A-Z and 0-9 as input.

~~~
Dylan16807
Half the time a bank doing that is also reducing everything to a numeric pin
and/or strictly limiting its length. Banks, on average, are a very bad model
for password security.

~~~
qzw
That’s undoubtedly true, but brut force password cracking is something that
banks have a relatively easy time of detecting and defeating, so one could
argue that the length/char limitations are not as big a problem. I’m far more
concerned that many banks (at least in the US) still only offer SMS as a
second factor, or even worse, use those horrible “security questions” and call
that two-factor authentication.

~~~
cryptonector
Yup. SMS is woefully insecure.

------
jdxcode
For the Heroku CLI I used this in some node.js code:

    
    
        sh -c "read -s PASS && echo $PASS"
    

I'm pretty sure it supports UTF-8 (only because I never heard otherwise. It
does require Git to be installed on Windows for sh.exe but that was a
prerequisite for our CLI anyways.

------
paulmooreparks
From the article: "I chose int for the length rather than size_t because it’s
a password and should not even approach INT_MAX."

That's the wrong reason to pick int over size_t. Am I missing something?

(EDIT) Especially since he calls it this way in the sample:

int len = read_password(password, sizeof(password), "password: ");

------
yrro
I'm surprised getpass(3) is marked as obsolete, it seems to be preferable to
implementing the steps described for a unix-like system in the article
yourself...

Maybe it's because it only reads up to PASS_MAX bytes, although glibc does not
suffer from this limitation...

------
suresha
Hii

