× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



On Tue, May 30, 2023 at 10:44 AM Patrik Schindler <poc@xxxxxxxxxx> wrote:

As said earlier, do not use "special" chars which are prone to translation due to different code points in different CCSIDs. Period. Peter Dow gave you small table.

Change your password over the correctly working Mocha to something without the @ sign. Problem solved.

If this answer doesn't satisfy your demand, you're probably on your own. If you think recycling passwords is a good idea: it's not. I have no other idea why you insist on an @ character in your password.

I hope by now it is well established in this thread that '@' and other
variant characters should be avoided.

I don't think the expectation to be *able* to use '@' in a password
necessarily has to do with wanting to recycle. I think it mainly has
to do with the idea that using "special characters" increases password
strength. And this idea is reinforced by many sources. It is often
considered a "best practice" by IT departments; and many, many sites
force you to have a special character in your password. Sometimes they
even specifically won't accept a password *unless* it has one of the
problematic characters Peter pointed out.

But mathematicians, and particularly cryptographers, I think agree
that the best way to increase the security of a password is to make it
longer. A 30-character phrase that you can easily remember, made up
entirely of alphabetic characters, is VASTLY stronger than a
10-character jumble of letters, digits, and punctuation, for example.
(In this day and age, 10 characters, no matter how random, is probably
not strong at all.)

While it's true that having special characters makes a password
stronger than not having special characters, for a given total length,
I think it's both a bit funny and a bit sad that even at QPWDLVL 0,
IBM allows '$', '@', 'and '#' (the three characters Peter listed as
variant). I mean, it's largely IBM's own problem that there *are*
variant characters. I have never heard of this kind of thing coming up
with mainstream platforms.

I don't know of any convenient way to *enforce* avoidance of these
characters by the general usership. It would be both more secure and
more resistant to these translation issues if there were a password
level that disallowed variant characters as well as rejected passwords
shorter than some minimum length. Even QPWDLVL 3 allows passwords as
short as 1 character.

Ah, and btw. saying "thank you all for helping" doesn't hurt.

Very true. But I will give OP some credit for keeping their cool in
the face of repeated lines of inquiry and suggestions that I would
have found intolerably annoying. In their position, my frustration
probably would have spilled into my posts at some point. (Like "I
already answered that." And "As I already said, from the very
beginning, many, MANY times now...". And "yes, of course, I know that,
I already tried that, many, many times. I tried everything you told me
even before I asked anyone for help." I might have started challenging
some people's ability to read, etc. The fact that OP just calmly
repeated what they said, and responded basically without complaint, is
already quite something in my book.)

But yeah, no "good" solution for the '@' within a password. Get rid of
it. Make it longer if you want it stronger.

John Y.

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.