Tag Info

New answers tagged

0

To expand on Ohnana 's answer, yes this is possible. If you were to create an application that essentially looked exactly the same as the bank's login screen, it could scrape the credentials and crash like they suggest. However, when you do that, and people start reviewing your app, it will be heavily rated on the bad (1-2 stars) side, which decreases ...


2

Well, the app is certainly possible. If the app was created for good by a bank, it can be recreated for evil. Especially if the evil app doesn't actually need to handle banking transactions. It could just scoop the credentials and crash. I think the other half of this question is "Are people dumb enough to fall for this?" Absolutely. Stupid is a renewable ...


0

I guess the policy is there to prevent virus infections because the computers are a Group resource and not a personal resource (eg, employees can take any PC that is available, the employee does not have a assigned "own" PC for the whole employment period). In this case, I would recommend running some sort of kiosk/readonly solution. One example is booting ...


0

This is where company and security policies can come in handy if you don't want to get all too technical. However if you do not require the need to write to mass storage devices via USB then you can simply edit the registry to only allow for devices to read via USB. Although, if you're staff do need the ability to read/write there are other registry related ...


5

There are potential technical options you can pursue, and several of those have been mentioned in other answers, such as global policies or BIOS settings to disable the USB ports, or physically disabling the USB ports. However... My suggestion is that if you have a systemic problem with this sort of thing, it isn't, in fact a technical problem at all, but ...


0

The problem with this is the availability of USB ports... if the USB ports no longer work, then they will stop trying it. I know there are group policies that disallow the use of USB ports through the OS, but I'm not too familiar with if there is a policy that will disable them entirely. If not, then you might be able to either A) disable USB in BIOS or B) ...


-1

Alright, ultimately the sensible answer is to provide charging points for everyone at the desk, so noone gets tempted. And, I'm sure you have a group policy in place that stops you from doing anything right? In linux, you could probably implement this as one of the udev rules.


-1

Glue the usb connector shut. No BYOD. Put it in writing, and have a workshop.


0

It's been a while since I last worked closely with Lync server, but while you can exercise quite a bit of control over the content of the conversations, I don't believe that it directly allows for Activesync style encryption policies. I sadly no longer have a configured environment to go digging on to verify that though, so take this answer with a large ...


0

No. You should not click install the app. The process I go by is quite simple: So back to the simple process again: 1) What is the app doing? 2) What are the permissions? 3) Is that permission really needed? Now let's look at a simple example. What is the app doing? Eg: Simple text editor.(Read/Write stuff from/to files) What are the permissions? ...


0

No you should never click "install the app" if you don't know/trust the developer neither on mobile nor PC. If you used to install everything on PC that's your problem, but you shouldn't do that because anything you install has full access to your data (worse, many installers require administrative privileges which means they get full access to your system, ...


0

If you mean "trust" in the communications sense, you're defending against man-in-the-middle attacks, and that means using HTTPS. For bonus trust, use certificate pinning in the mobile app. If you mean "trust" in the "server wants to ensure that the client has authenticated" sense, you should read more about OAuth. The short of it is that Your user will ...


2

What is your threat model? If every connection is sent over SSL, you do not need to worry about anyone sniffing your communications. This is actually the strongest part of your system. Good job choosing something standard. Because SSL is ensuring nobody is listening in on your communications, we should look at the endpoints. Your UUID is basically a ...


5

Just use TLS, it's what it was meant for: securely send data between two parties across an untrusted channel. Should you want additional protection, there are two ways to solve this problem that spring to my mind: Use a password to encrypt the symmetric key Use a token such as an OTT through SMS or generated using a smartcard and external cardreader ...


0

For android phones, there is a credential storage that allows you to store keys. It runs as a system daemon and uses AES to encrypt the keys. The keys are tied to the UID of the app that created it so other rogue apps are unable to access these keys. For iOS, there is a similar keychain which serves a similar purpose. It is also encrypted and sandboxed so ...


2

There is a project called OASAM that aims to define a methodology to test Android devices. You can find it here: http://oasam.org/en The guide has the following sections: OASAM-INFO: Information Gathering: Information gathering and attack surface definition. OASAM-CONF: Configuration and Deploy Management: Configuration and deploy assessment. ...


3

Yes, it loses some of the protection since it fails to protect them if the device is thoroughly compromised. It still, however, protects against any number of limited attacks. For example, if they are configured to connect through a proxy that can strip the encryption, the 2FA will remain safe. If the password DB is compromised somewhere that they used ...



Top 50 recent answers are included