Score:0

Server

How to show a password-containing automated generated image, whose "content" is "copyable"?

Dominique

3/28/24, 11:59 AM

I'm responsible for a MediaWiki in my company. That Mediawiki contains information, like passwords. Currently those passwords are stored on the server, hosting the MediaWiki, but when a person surfs to that MediaWiki website, the traffic is not encoded (when I use a simple sniffer, I can read the passwords).

There are different approaches to such an issue:

I can turn the MediaWiki website, who is currently based on HTTP, to HTTPS. This is handled in this previous question, but it means that I need to reconfigure the MediaWiki website.
(This is a product of my imagination) I could use a "special component", who reads the password, turns it into an image and shows the image on screen. That "special component" allows the displayed text to be copied/pasted.
(For your information, a MediaWiki-page's URL looks as follows:
"http://<server-name>/wiki/index.php/<page_title>")
Simply said: turn "text" into (and make it "copyable").

As for the second question: does such a "turn-text-into-an-image"-component exist and if yes, do I need to do something in order for my MediaWiki to use it?

1 + 9

security

image

text

mediawiki

Dominique

3/28/24, 12:10 PM

Thanks for the quick reply, but I prefer not throwing everything away: the MediaWiki is a good way to store information, the passwords being a part of that information, so I prefer to keep working like this.

Nikita Kipriyanov

3/28/24, 12:12 PM

And yet, don't store passwords in it. I understand your desire to store everything coherently, but passwords are sensitive information which absolutely require a specials treatment. Yes, when you design secure systems, you often split information to parts which have different requirements and store them differently, *this* is how things are done. Various FIPS standards require it, for example, and that's for a reason. So it is important enough to throw everything away. Heck, passing keepass database around is better than storing passwords in mediawiki.

vidarlo

3/28/24, 12:19 PM

This is simply not ***reasonable information technology management practices***. It's asking to store passwords in a tool totally unsuitable for storing credentials - and *using security through obscurity* to *secure* those passwords. It's about as bad as it gets.

Nikita Kipriyanov

3/28/24, 12:20 PM

I only bothered to answer to explain this is bad. Because this is how you can reach people. There could be no other answer than "don't do this, this is deeply wrong; do that".

Dominique

3/28/24, 12:41 PM

I see the point that putting passwords in a MediaWiki platform is bad, so there are some proposals to use "password storing and sharing tools", but can those tools be used for storing normal information too ((formatted) text, images, ...)? I mean, it's the idea to keep as much information together, instead of one tool for the explanations, one for the passwords, one for ...

Nikita Kipriyanov

3/28/24, 1:14 PM

Yep, you **must** use one tool for passwords and other sensitive information and another tool for everything not that sensitive. (That is if you have only two kinds of data; in some cases you need to use more systems with gradually stronger guarantees, like third tool which requires at least two people to unlock, for very secure information.) Your idea "to keep information together" is what is wrong here. Some information must not be kept together, no matter how strong the desire is. Or, find a password manager with wiki-like features, I hope it exists, and use it for everything.

Nikita Kipriyanov

3/28/24, 1:23 PM

There was a moment when I coined the idea to have a plugin for DokuWiki where we kept all the non-secure information, which will do password storage securely, but managed and searched together with the wiki. Boy, this happened to be *extremely hard* to do properly. I gave up.

Dominique

3/28/24, 1:28 PM

Exactly. Therefore I would opt treating all information as sensitive (which, by the way it is). But then we get into a situation where a colleague needs to connect to a customer's system, clicks on something, answers some questions and the VPN gets set up and the RDP connection is used, both automatically. I bet this goes beyond the "password storing and sharing tools", which you have provided in your answer.

Dominique

3/28/24, 2:04 PM

@NikitaKipriyanov: did you ever hear of ConnectWiseControl? It looks like a tool I might use for this purpose, but if it's as unsecure as a MediaWiki, it's not a good idea :-)

Score:4

Server

Nikita Kipriyanov

3/28/24, 12:08 PM

Simple.

Don't do that. Don't store passwords in a MediaWiki. Don't show them on screen. Don't think that rendering text as images makes it more secure.

There are a multitude of tools which are dedicated to storing and sharing password securely, with proper ACL controls, emergency push button to disable access to the database, secure entry into various forms, and so on. Use them:

And so on, search for yourself.

+ 8

Dominique

3/28/24, 1:10 PM

Let me explain you the idea behind it all: in my firm people sometimes need to connect to users' systems in order to work remotely on the customers' computers or PLCs. This happens through VPN connections, followed by RDP connections. Until now this is done, putting all information in a MediaWiki and I'm looking for another solution. I started my idea by replacing HTTP by HTTPS, then by transforming the passwords from text to images, but apparently it seems not to be good enough. Whatever solution I find, it must be very easily usable for my colleagues.

Nikita Kipriyanov

3/28/24, 1:19 PM

Educate your colleagues (and yourself) on security and how to do things properly. If they are unable to learn, fire them for incompetency. Unfortunately, secure things are often not so convenient and easy to use; that's the price you pay for the security. To manage an AD in our organization, for example, one has to use physical security token to authenticate. No way around. Not very convenient, but secure.

Dominique

3/28/24, 1:22 PM

Pardon my lack of knowledge, but what's an AD?

Nikita Kipriyanov

3/28/24, 1:24 PM

Microsoft Active Directory. One can not became a domain admin and administer users, computers, policies, etc. without the token.

Dominique

3/28/24, 3:05 PM

For your information: I'm now doing some first tests with the Remote Desktop Manager from Devolutions.net. I'm already able to open some RDP sessions without VPN, tomorrow I'll do some tests using VPN. If everything is working fine and if the DataSource (containing the sensitive information) is secured well enough, I might replace my MediaWiki by this tool. Thanks a lot for your support.

Ginnungagap

3/29/24, 4:40 AM

I don't know the tool but just looking at the homepage, I do hope you're talking about the Team Edition which includes RBAC and Audit. You absolutely cannot (continue to) manage systems, let alone client ones, without the bare minimum of security and accountability. If a client gets compromised (and more likely given the situation, if all your clients do) because of your company's poor security practices, you'd better have airtight contracts that relieve you of any and all responsibility.

Dominique

3/29/24, 1:59 PM

@Ginnungagap: first I'm trying to make the tool work: it works quite easily with single remote connections and well-known VPN systems are ok. I've managed getting Pulse Secure to work, but now I'm in the middle of a Two-Step authentication. If all those things work, I'll have a look at the Team Edition, for the reasons you mentioned.

Ginnungagap

3/29/24, 6:02 PM

You've got quite a bit to catch up on so good on you that you're actually moving in the right direction. It's easy to criticize, it's harder to change things that are rooted deep in people's habits

Elon Musk

I sit in a Tesla and translated this thread with Ai:

EN: How to show a password-containing automated generated image, whose "content" is "copyable"?

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.