This is intentional, protect your computer instead.

If somebody gets physical access to your machine, nothing can help you.

What kind of answer is this. Of course I protect my computer. But you add layers of protection.
Every password app has protection in front and this should be default.
So if this is intentional, fix it, cause it is very bad practice.
Even mRemoteMG has this feature. Plus in mRemoteMG you can't view your password either.

I have rephrased my request, perhaps that makes it more clear.

This is intentional, protect your computer instead.

If somebody gets physical access to your machine, nothing can help you.

If it’s intentional then that is very poor security, I’d love to see an extra layer applied as the OP has suggested. It makes sense, particularly in this day and age of cyber warfare.

No, very poor security is leaving your computer accesible.

There are number of apps that do this the same way, including web browsers.

While this certainly can be done, I consider it to have very low priority.

I've not seen a browser that does this.
Maybe netscape.

No, very poor security is leaving your computer accesible.

So the first layer of security fails, you think its acceptable for a lacklustre app to open you up to a plethora of other issues?

I sense a severe lack of understanding of security fundamentals from the devs on this one...

@majkinetor This is different from the use case we previously discussed.

OP suggested that a secondary authentication be required to display passwords, our previous discussion was about the startup password for the app and the need to enter the password again after being away for a period of time.

I don't think the startup password for the app is very necessary, but a secondary confirmation for displaying passwords could be useful. I've had a few instances where I need let friend use my PC temporarily, and they can copy my remote system passwords directly form 1Remote if they want.

append

However, after thinking for a while, I realized that having only a secondary verification for viewing passwords will still has a problem, as my friend could simply copy my database without guessing what the password is.

So it is necessary to use the password to encrypt the database to ensure security. However, since we now support multiple databases and database sharing, there may be that two databases use different passwords, it will be a challenge for both system development and user experience.

append2

Even if the databases are encrypted, my friends could still copy my entire system environment to their PC. Then although they wouldn't be able to view the passwords, they would be able to connect to my remote system. （This is because the encrypted passwords need to be stored somewhere in the system, otherwise I would need to enter the password every time I opened 1Remote. Especially when I connect to multiple databases, I don't want to have to enter multiple passwords before I can use 1Remote.）

@majkinetor This is different from the use case we previously discussed.

OP suggested that a secondary authentication be required to display passwords, our previous discussion was about the startup password for the app and the need to enter the password again after being away for a period of time.

I don't think the startup password for the app is very necessary, but a secondary confirmation for displaying passwords could be useful. I've had a few instances where I need let friend use my PC temporarily, and they can copy my remote system passwords directly form 1Remote if they want.

append

However, after thinking for a while, I realized that having only a secondary verification for viewing passwords will still has a problem, as my friend could simply copy my database without guessing what the password is.

So it is necessary to use the password to encrypt the database to ensure security. However, since we now support multiple databases and database sharing, there may be that two databases use different passwords, it will be a challenge for both system development and user experience.

append2

Even if the databases are encrypted, my friends could still copy my entire system environment to their PC. Then although they wouldn't be able to view the passwords, they would be able to connect to my remote system. （This is because the encrypted passwords need to be stored somewhere in the system, otherwise I would need to enter the password every time I opened 1Remote. Especially when I connect to multiple databases, I don't want to have to enter multiple passwords before I can use 1Remote.）

You are correct with the appends.
Yes you can share your DB with people and they could use the stored info. This same behavior is present with mRemoteNG.

You could add a startup pass. This will apply to all DB files. So if one would share it, it would need to know that password. Because it would ask when opened.
If you you import a DB while you already have a DB with different password, it will only ask the newly added DB password once. Then saves the added DB with user's own master password.

I sense a severe lack of understanding of security fundamentals from the devs on this one...

I sense you should use another program wtih "more" security :)

There is very serious lack of understanding of security here for sure. FYI, keylogers are a thing! Please inform yourself better before accusing other people of lack of understanding.

Hey everyone, let's calm down, OK? It's true that password protection is a weak point for PRemoteM. suggestions are valid, but we also acknowledge that when someone has physical access to your PC desktop, any security measure may be fail. @majkinetor @beasthouse-au Both of you are just focusing on different security points, so there's no need to blame each other.

There is also a personal taste for me. I'm too lazy to enter a password every time, so I tend to sacrifice some security for convenience (because I can almost ensure the security of my PC). That's why I haven't added startup password protection and have given this feature a low priority (to the extent that I can't find the previous discussion about the startup password now).

That's why I asked for it to be optional 😁
If someone wants it, they can enable it.

Here it is:

• https://github.com/VShawn/PRemoteM/wiki/Security#why-premotem-dont-need-a-activation-password

Also: #429

That link seems a bit outdated and not really up to par in modern ages.

@bokkoman you need to provide argumentation for your claims, otherwise your stance will get ignored.

Like I said, earlier, physical access to your computer makes any protection you have void because its trivial to circumvent it (unless you use strong encryption). There is even old adage if the bad guy gets physical access, the computer is no longer yours.

What we have currently is password hiding via asterisk which is to prevent shoulder surfing.

Like I already said, major tools dont do this, here is a screenshot from Firefox:

Imagine what happens when I click the eye button. The same is true for Chrome. Its because they know password is useless.

Now, If we imagine this will get done one day, for whatever invalid reason, I would personally not use any kind of solution that doesn't prompt with OS password. It could easily be tested with equivalent of this:

$PlainPassword="your_password"

$tmp = New-TemporaryFile
$SecurePassword = $PlainPassword | ConvertTo-SecureString -AsPlainText -Force
$Credentials = New-Object System.Management.Automation.PSCredential -ArgumentList $Env:USERNAME,$SecurePassword
Start-Process whoami -Credential $Credentials -RedirectStandardOutput $tmp
(Get-Content $tmp -ErroraAction ignore) -like "*\$Env:Username #true if password is OK
Remove-Item $tmp -ErrorAction ignore

Its trivial to do and doesn't require from user to do anything apart from maybe enabling it in config.

However, its invalid, because its trivial to cirmuvent by having access to the computer

1. You can just open the SQLITE database
2. You can use start/end script with echo %PASSWORD% as it is passed as env var
   1. Now you should lock config changes and if script is set, keep script hashsum to prevent external modification
      1. Which is again easy to circumvent as you can just inspect the environment of the started connector

So you have to be extremelly unmovated to not get ones passwords. It could stop little kids and babies though 🍼

Now, what could be done. We could save passwords in Windows Credential Manager instead of the database directly. This is how RDP actually does it nativelly. However, those are easily obtained once you have access to the OS - if you have access to username, its trivial, because you have an eye button again :) If you have another users, there are number of tools that lets you hijack OS.

#466