How To Unlock A Rar File Without Password

1 view

Skip to first unread message

Annette Fazzari

unread,

Aug 3, 2024, 4:50:40 PM8/3/24

to gedphosacco

I have an account with an old email address I am not using anymore, on top of that I also forgot my password. So I would just like to delete the account altogether or change the email address or password.

Did this post help you? If so, give it a Like below to let us know.
Need help with something else? Ask me a question!
Find Tips & Tricks Discover more ways to use Dropbox here!
Interested in Community Groups? Click here to join

I have an old Dropbox account that is using Sign-in from Google . I am trying to delete the account as I want to associate my email address to my active Dropbox account. I cannot delete the account nor can I change the email address on the old Dropbox account as it prompts me for a password. I tried the password associated with Google but that does not work. Can someone point me in the right direction please?

Ok I think I found the solution. If you used an externally validated login service such as Google to login to your Dropbox account, deleting your account or changing the email address associated with your account may be a challenge. The reason is that Dropbox prompts you for a password which presumably is used to attempt to validate your credentials using the external service. I suspect this won't work because it needs to send more than just the password. If you change your password, then you go through the process of moving your security validation to the standard username/password type as opposed to utilizing the external service. This will allow you to delete your account. This worked for me.

Note that there are legitimate reasons for logging in via root (but using cryptographic keys and never a password). A typical example is remotely syncing two servers (to have one of them being used as fail-over). Because the structure must be identical, often a root password is required.

We sell a few next-gen AV solutions and have had really great results (no infections) so far. We did however blow holes in almost every other solution out there and combine that with massive amounts of system resource utilization it makes it hard to recommend keeping both installed.

An offline device that cannot access the console to make changes to the Self Protection Level or Prevent Service Shutdown settings, changes will need to be made manually to the registry to help uninstall the product.

Had to edit this severally to keep it short and stay on topic:
I have another post here but this one was just about figuring out how to remove Cylance without the password, while other things gets figured out.

About the slow logins, I expect to have to do more work to get that sorted out between the AD servers and TrendMicro, this issue the users report starting after the recovery from the malware and the only changes since was the AV and the new DC.

To change this, click on the Advanced button, then click Change next to where it says Owner (which for me was SYSTEM). Now it should be asking you to select a user or group. Click the Advanced button. Then click Find Now and select the administrative account that you are using (I simply went down to Users). Select the account and click OK and it should populate into the white box that says Enter the Object Name to Select(examples). Click Ok again. It should pop up with a message telling you to close and open properties again for this change to show up. Click through the messages saying ok until they are closed, then right click on the file again, go to Properties, Security, then you should be able to edit the rights of your profile to Full Control. Once this is done, you should be able to successfully remove the application via Add/Remove programs.

I could neither uninstall nor reinstall because the cylance service was locked by the built-in service account and would not stop. the cylance service would not stop, nor could I (admin) stop it manually.

Well, so I say to myself "Ok, that means that if I have a file refered in sudoers as I did, it will work without prompt only if I call him with sudo, what is not what I want".
So, ok, I create another script script2.sh as following :

I want to insist on the fact that this "apt-get update" was just an example FAR from whhat my script actually is. My script has a lot of commands (with some cd to root-access-only config files), and the solution can't be "Well, just do it directly with apt-get".

I suggest you look at the sudo environment variables - specifically you can use (and check for) $SUDO_USER. Call your script with sudo (1 entry in sudoers), then do user stuff as SUDO_USER and root stuff as root.

Simply, in order to execute commands as root you must use su (even sudo uses su)As long as you execute sudo ./script2.sh successfully just instead : sudo su "#" //commands as root here "#" exit//commands as use hereyou can make it a shell function with the name sudo, but no other better way i think,however it's the case with scripts inti,rc android ..etcmust be tidy ;)

However, you should consider this feature to be a deterrent but not a guarantee that the people that you share the password with won't be able to ever view the password. Our permissions only apply to the 1Password apps and not to other apps like the browser. If they use 1Password in the browser to fill the password into a website then they could use a tool like Chrome's Developer Tools to view the filled password on the webpage. You can read more about the limitations of this permission here: How vault permissions are enforced in 1Password accounts

You're right, I was talking from a family account experience. I was looking into moving to a business account, in parallel to my family account. I assumed both would function the same, way, 100% my bad.

From a security point of view : there is no known way of sharing accounts in a business that doesn't imply (1) an implementation of multi-users from within the service/app I need to share or (2) actually sharing the passwords (with all the limitation you explained)?

I'm thinking about these possibilities, but all have limitations:
1/ changing all apps' passwords weekly (to limit sharing outside the organisation) : as costful in time as managing access within apps, without proper protection.
2/ setting up computers with all apps' logins, giving them access through a VPN: they can still access passwords if they are determined to do so.

Thanks for the reply. You should only share a password with someone that you trust to have that password. Otherwise it's best not to share it at all, even with View and Copy Passwords turned off. As our guide to vault permissions says:

It sounds like you're giving your trainees limited access to a lot of different apps/tools. A lot of business use a centralized identity and access management platform, such as Okta, to avoid having to assign, share, and manage passwords. That would likely be the best option but it would require work and support from all of the different apps and services that you use. You can find 1Password's guide to Okta here if you're interested: Configure Unlock 1Password with Okta

Alternatively, I know that some businesses only allow access to their tools within a specialized environment that they control completely. For example, you could lock down the browser so that developer tools can't be used. You could setup this kind of locked down environment and then enforce that your trainees use a VPN to access the environment if they work remotely.

On some computers we are able to enter just a password to gain unattended access to a computer in our organization. However, on others, we are required to enter in a username (apparently this is set by the computer) and a password. I have poured through the Control Panel and Web GUI settings looking for the option to remove the need for a username and just have a password (most computers are being used as remote monitoring tools with no human user physically on site) but have been unsuccessful. Any answers?

After going back and forth with their support for a few weeks over email, I finally got a resolution. They let me know that it's a bug in the software. To get the option to enter in an unattended password (User Access Code) without the need for entering in a username specific to the LogMeIn Client on each computer, you have to completely delete LogMeIn for the PC. Then re-download it and you should get the option then. A bit of a round-about solution, but I've tried it on a machine or two since and it's worked for me.

At least twice now - once on my phone and once on windows desktop - PayPal logged me in to authorize payment without even asking for password or even showing a login in screen.
I tripled checked that auto-log in is turned off and I find nothing labeled "one touch".

Also double checked that there are no logged in devices. And no websites I don't want with info access (only PayPal community, in fact).

And yes, I double checked that the log in Info is no memorized into my browser either, though that would not have explained it.

So what's going on and how do I stop this SERIOUS security breach?
It's almost like PayPal is intentionally trying to compromise my security.