What are some of the benign use cases of injecting bytes into another process and creating remote thread? Lets say, you are developing an AV, and marked any type of injecting into another process (for example openning it and writing to it) and creating remote thread malicious.

If so, what will be some of the false positives? will a normal user who just wants to install normal apps and browse the web be effected?

I just don't understand why would an benign app need to do this? And how common is it? For example, if it is only 1 in a billion benign app that does this, then why allow it at all?

Well the problem with this approach is that the injection happens
using the WinAPI which is also used by native windows applications.
A very common chain that has been out there in the wild for a while now
is the following one:

OpenProcess -> VirtualAllocEx -> WriteProcessMemory -> CreateRemoteThread

and variants. If you notice all of the above functions are part of the WinAPI.
Now let's study what exactly each of these functions do. From the MSDN docs:

  OpenProcess: Opens an existing local process object. The access to the process object. This access right is checked against the security descriptor for the process.

So this is a simple function that justs allows an application to get a handle and interact
with another process if it has the appropriate rights. This is very common to happen on windows
for various applications.

  VirtualAllocEx: Reserves, commits, or changes the state of a region of memory within the virtual address space of a specified process. The function initializes the memory it allocates to zero.

So again this function can be used to allocate some memory space which is useful
if e.g. someone wants to make a custom memory manager for an application. Even malloc
which is used a lot in C/C++ programming in its core uses VirtualAllocEx and variants.

  WriteProcessMemory: Writes data to an area of memory in a specified process. The entire area to be written to must be accessible or the operation fails.

Well, what is the point of allocating space if you can't write to it (if you have the
appropriate privileges/rights of course).

  CreateRemoteThread: Creates a thread that runs in the virtual address space of another process.

Creating threads is useful for many reasons. In this case - it is just a way we can execute the process we already have a handle for, using OpenProcess from above.

In addition a variant of the above routine is also used for DLL injection/hooking which is used e.g. by software debuggers.

So as you can see this technique is often used to inject malicious code but it is also used by built-in applications. For this reason there are other techniques (e.g. code signature etc...) to prevent malware infection/injection. The bad news is that unfortunately there are also ways to bypass some of these techniques.


Force user to download a file to their hard drive via hyperlink? I want to design a scenario in which I have a web site which contains a link. If the user clicks on this link, it will save a file in a specific pat in his hard disk without his consent. Is this possible?

The browser is typically sandboxed from this type of system interaction just using JavaScript, localstore, etc.

If you have plugins and can run Java Applets its possible. There should be warnings that pop up, but one could use social engineering to trick them into click this. You could probably just get them to download an executable and home their anti-malware settings don't block it.

Beyond that you would need to exploit a flaw in the browser's implementation of some spec or security design.

Some useful links:

Flash Sandboxing (OWASP)
The File System API Proposed (Dead) Spec
Sandboxed vs Privileged JAVA Applets


Question about email app in Python and security I've managed to get my tiny little app to send an email with a click of a button using this code (this is just the email part): http://pastebin.com/nR5g28ct

But to avoid some error, I had to allow less secure apps in my account using the steps seen on this google support page.
Gmail told me that's kind of bad thing, so I was wondering, is it really unsafe to do this? I was thinking about adding receiving emails also, but now I'm not so sure and I deleted my info from my source code even though it's just on my laptop and no one else has access to it (paranoid much?).

I ran into the same issue when using a Ruby gmail gem.

According to this post, "less secure apps" directly handle your credentials, rather than using something like OAuth that verifies your identity without exposing your credentials to the app. Given that your app is running locally on your machine (and you hopefully trust it!) this shouldn't be a problem.


PCI scan shows unknown vulnerabilities Basit Submit Module Cross Site Scripting Vulnerability

DCP-Portal Cross Site Scripting Bugs, CVE-2004-2511 CVE- 2003-1536 CVE-2004-2512

These two vulnerabilities have been identified in the scan done against our website by a 3rd party reviewer. I'm unable to resolve these issues. Can anyone shed some light on these and how to resolve them?

As previously mentioned in the comments of the question.

It will be best to look at the HTTP headers

I have included an answer to a previous question, which can be used to address these issues.

https://stackoverflow.com/a/10369475/4962088

https://geekflare.com/http-header-implementation/

It is also worth looking at validation when creating a website/web application, which can be seen using the link below.

https://stackoverflow.com/a/1996141/4962088


How to safely allow scripts but preventing XSS? We are trying to find the best way to allow JavaScript in a web application while being safe against XSS.

Site admins have the privilege to insert JavaScript to control the site templates, and publish this to site users. However, site users cannot insert JavaScript.

I know allowing JavaScript will open up a XSS vulnerability, letting site admins steal sensitive info from site users. Is there a better way to allow JavaScripts for site admins?

Either run them in a cross-domain iframe, or use something like Google Caja to isolate them.


Evasion techiques for WAFs Are there any documented techniques for evading Web application firewall for testing WAF rule configurations?

It can be difficult to predict how a WAF will inspect traffic because WAF rules and methods are not standardized and work so high up the stack. Basically, you are looking for weaknesses in detection and/or to make it as difficult as possible for a WAF to properly interpret the communication sent to the target.

Some techniques that can be used:

mixed case in attack strings (used to by-pass WAF regex configurations)
random comments in SQL commands
URI encoding
packet fragmentation

In one simple home-grown WAF system I tested, I defeated the SQL injection protection by switching from

' OR 1=1 --

to

' OR foo=foo --

On the topic of tools, SQLMap and Havij are well-known. The SQLMap evasion scripts may also provide deeper insight into specific WAF evasion techniques.

Any IPS evasion technique can also be potentially applied to WAF.


How prevent Javascript from obtaining my location I usually use a proxy server to browse anonymously. Now I realize that it is possible to find the location of a user using the Geolocation API. How to anonymously browse without disabling Javascript?

If you want to be anonymous and are worried about geolocation, don't grant websites access to your location.  You will be prompted about whether to allow a website to access your location before the website can use HTML5's geolocation feature to locate you; make sure you don't allow it.

More generally, follow all the standard strategies for surfing the web anonymously.  For instance, use Tor, and use it properly.  There's a lot already written on this topic on this site; use search to find it.  See, e.g., Different strategies for online anonymity and their +/-s?, How to be completely anonymous online?, How much can I trust Tor?,
What are the pros and cons of a VPN for privacy,
How can I use a VPN to protect my privacy,
How to browse the Internet safely?, Does Java applets reveal the real IP address, even when using proxy or vpn?, Improving the privacy of a casual Web user,
Is it possible to Identify a VPN user by finding relations in traffic?.


How to be safe from wifikill! I recently found that my friend is using wifikill apk on his rooted android and I would like to get rid of that software as I always get kicked from my wifi. I have to give him the password of my wifi but he his been doing such things and I am pretending like I don't know.

Is there anyway that I can make his wifikill not work in my router and in my network?

WifiKill uses a simple ARP spoofing, i.e. it floods all the devices on the WLAN and attempts to impersonate the access point.

There is nothing you can do on your device as is (rooting changes matters: see below) - you would need to deploy an IP filter on the same, and drop all ARP packets. This would prevent you from talking to any device in the WLAN. To be able to do that again you would need to manually prime your device's ARP cache with values you know to be correct (a.k.a. static ARP entries).

Social engineering

You could ask your roommate to quit being a jerk, and/or establish some acceptable usage policy and/or timetable. Why does he need to use WiFiKill? Does he need to?

But supposing you don't want, or can't, get him face to face... and assuming you do have the right to the connection, i.e., it is (in part at least) your access point and Internet connection, not his... there are ways.

You can start making life difficult for him, and have him perceive it is caused by his behaviour, without ever saying so. For example: you can start complaining about your unstable access point and begin resetting it to factory defaults every now and then. Change your WPA key and give it to him again, saying you had to reset the blasted thing yet again ("it keeps disconnecting"). He (and you too) will then have to reinsert the key. After some time, he will come to understand that every time he uses WFK, he gains a few minutes' full bandwidth... and then no bandwidth, and a whole evening of listening to you whining and ranting about unreliable hardware.

You might start spawning conspiracy theories by asking him whether it is likely that there's an incompatibility between your (not his!) phone and the AP, or start noticing unlikely coincidences ("Every time the microwave starts, the connection drops"). After a while grasping at straws, you can latch on the real coincidence ("The network disconnects me only when you are home") and suggest he takes his phone to the shop for a repair. This will reassure him that you accuse him of no wilful wrongdoing -- but at the same time it will be clear that you're onto something. This could be a minimally confrontational way of clearing the air. You can tune the "coincidence" you notice, in order to try and work out a compromise ("Probably when you play online games on your phone a weird combination of bandwidth, access point chip brand and magnetosphere resonance disconnects my phone. Not anyone's fault, but still -- can you tell me when you're going to have a long gaming session?").

The same approach can be used to drive home economic threats ("We need a new wireless access point with a stronger antenna. I found one for $180 -- if this AP reset I'm going to try does not work, we'll need to think about purchasing a new AP. How much could you contribute?").

Android apps protecting from WiFiKill (root may be required)

I am far from sure since I haven't tested it personally, but this seems what applications like ARP Guard, ARPProtect or WiFi Protector do. The latter explicitly mentions WiFiKill. Downside: to fully protect a device you need to tamper with its network stack at a low level, so defense needs root too.

iOS

I have no experience on iOS (editing is welcome!), but there are hints that iOS7 employs some ARP spoofing mitigation techniques - possibly slow-caching, glean-refusal, gratuitous-refusal or others. Owners of iOS7 devices might have nothing to worry about.

Built-in access point protection (and its drawbacks)

There is also another way, but it depends on the access point.

Some access points have a special mode of operation - sometimes called "Private Mode", "Client Isolation", "Guest Mode" or "Privacy" - whereby, however large the pool of devices connected to the AP, you only see yours. You cannot "talk" to the other devices. The AP will accept packets from you to it, and not forward any other except for NATting you on the Internet.

This allows e.g. users in a café to be relatively safe against their neighbours' curiosity - you might have a totally open system with services exposed on your laptop, but when you're connected to a private-mode AP nobody else can see them.

I believe that an ARP spoof in such a setup would silently fail. The down side is, not all access points support this.

VERY IMPORTANT: if you have any WiFi device you need to access, e.g. a WiFi printer, it will not work in Privacy Mode, and it might still not work if connected via ethernet cable to one of the Ethernet ports some "APs" have. If this is the case, you might have to query the shop for the exact APs features, or give up on this possibility.

UPDATE: some even fancier Netgear AP have the option of excluding a sub-pool of IPs from privacy mode. So you can have the AP as 192.168.1.1, the WiFi printer and DLNA servers as .2 and .3, use DHCP to assign addresses from .8 to .254 to newcomers. Your being assigned 192.168.1.34 will tell you that there might be (or have been) other (33-8) = 25 devices connected, but you will only ever "see" and be able to harass .1, .2 and .3.

ARP filter on AP

Several access points have the feature of filtering ARP in various ways. This can occasionally break other technologies, notably iOS AirPrint, that rely on ARP "openness", but it may be worth pursuing. On some systems this goes under "bandwidth protection".

Most APs based on Atheros AR5002G should either have the feature available, or it can be activated with the appropriate hack (see below).

Adding protection to the AP if not built-in (not for the faint-hearted)

If you're feeling adventurous and your AP supports it, you could try and flash it with a version of DD-WRT supporting client isolation or some flavour of ARP filtering.

Or you can say that you've had it with your faulty APs that always disconnects, and you buy a new AP which already has, and accidentally comes already configured with, Privacy Mode and/or ARP filtering.

A different approach, again AP-based

Another possibility, also available on some APs but not all, is the "split SSID"  or "Twin SSID" mode. In this mode the AP publishes two SSIDs, with different keys. In some APs you can also set the bandwidth limitation for one or both networks. You can then get even with your "friend" by copying the current SSID and key to the guest or low-bandwidth connection, then giving the other SSID the name of your neighbours' daughter or pet. Of course, if he gets suspicious, a little investigation will reveal the truth.

In general

Several techniques are available to protect against ARP spoofing. There are some silver bullets, but they're not ubiquitous. The historical (and arguably outdated) tendence was to glob any ARP information you came about, and use it to improve network performance. This is an effective strategy, as long as you can trust that ARP information. Otherwise you need to only consider information you requested, and possibly refuse it if it looks suspicious, if the context seems fishy, or if some extra checks fail to deliver. To do so, of course, introduces a delay.


How to prevent "TSource Engine Query" DDoS attack? I recently started a game hosting company and one of my boxes is being hit very hard by what i believe is a botnet. We are getting thousands of IP addresses sending traffic to a port where a game server is located.

In total there was 2,613,561 packets sent from 40,000+ different IP addresses according to Wireshark. I rent boxes from OVH, and clearly their DDoS mitigation appears to not have any affect on this attack as it went on for over two hours.

AFter inspecting the packets with Wireshark, I found that the majority of them are directed at port 27115 (where a game server is located) and contain "TSource Engine Query" in the data:

I can provide the wireshark capture file if needed. I managed to capture packets for most of the duration of the attack.

What can I do to prevent this kind of attack in the future?

While I have not encountered such attacks when running game servers, I always had control over the box I was running them on.

In your case, you are being flooded by A2S_INFO requests, and according to US-CERT, this kind of attack is amplified by about 5.5x that of a "standard"  query and response for information over UDP.

Information Security deals extensively with risk management. As we will consider this attack as a risk, there are three options to take (or combine):

You can mitigate it:

Use an IPS or firewall to blackhole/shunt the packets by volume of requests.
Ignore requests from certain IP addresses (limited in comparison to legitimate traffic).
Cache the requests, and respond to new ones with a cached version.

You can transfer it:

Notify your service provider that you require specialized DoS mitigation.
Transfer to a service that understands you require mitigation of UDP traffic.

You can accept it:

While not an answer you may want to hear, it is valid only if you loose little with the downtime.

Additional readings:

https://www.us-cert.gov/ncas/alerts/TA14-017A

https://developer.valvesoftware.com/wiki/Server_Queries

https://forums.alliedmods.net/showthread.php?t=273129


What measures can be taken to make a site safe again after a hostile service worker is installed in users' browsers? So my understanding of Service Workers is that once installed they grant you full control over requests to a domain. If an attacker managed to include their service worker in your site, then for anyone who visited that site the service worker could be installed, and then for example proxy all further requests to the site. Removing the service worker's code from your site would not remove it from the browsers which already had installed it. A nefarious service worker could also hide any warnings you added to your site telling your users to clear their browser data - it could serve its own version of your site making any such changes completely ineffective against compromised users' browsers.

If my understanding of service workers is correct, the only way I can think of mitigating such an attack is to send warnings on other domains. For example, if the attack was on a subdomain you could warn on the main domain, but if the attack was on the main domain you might have to send out an alert on Twitter/FB etc. You may also be able to switch domains (or subdomains) away from the attacked domain, but if anyone whose browser bookmarked the compromised domain then they would remain at risk. Is this assessment correct, or are there ways of disabling a service worker that doesn't want to be disabled?

From your link:

  Installation is attempted when the downloaded file is found to be new
  — either different to an existing service worker (byte-wise compared),
  or the first service worker encountered for this page/site.

and

  If there is an existing service worker available, the new version is
  installed in the background, but not yet activated — at this point it
  is called the worker in waiting. It is only activated when there are
  no longer any pages loaded that are still using the old service
  worker. As soon as there are no more pages to be loaded, the new
  service worker activates (becoming the active worker). Activation can
  happen sooner using ServiceWorkerGlobalScope.skipWaiting() and
  existing pages can be claimed by the active worker
  using Clients.claim().

It sounds to me that the legitimate site should be able to replace the malicious service worker with a harmless one, once your site is visited again. Of course, you probably can't do anything about it until they come back to your site.

That said, there could be methods that I'm not aware of that allow the malicious service worker to prevent updates.


Why is it considered safe for services like Mint to store bank password? My understanding is that, typically websites are recommended to store only hashes of passwords using one-way cryptographic hash function. This way, there is no way to retrieve the passwords even when somebody can hack the database.[1]

On the other hand, financial management website Mint requires you to enter bank login information. Presumably they use this to access the banking information, so they would have to be able to store the password in a way that can be retrieved. Yet, most reviews that I read consider Mint safe[2]. How can it be safe, while adhering to a less secure practice of storing bank passwords than a typical website?

[1]For example, see Why is 3DES not used to store passwords?

[2] For example: Is Mint Ready for Your Money?.

We don't really use the concept "X is safe" in Information Security, because it is not nuanced enough. Instead, we have "X has a level of risk that Y will accept".

In order for Mint to work, they need to have your banking passwords so that they can log onto your bank and pretend that they are you. So they need to store them, and this adds risk.

(They can do all sorts of things to protect those passwords. They can use multi-layer encryption. They can have good physical security at their data centre. They can pentest themselves daily. See https://www.mint.com/how-it-works/security/security-technology/ for a list. However, hashing your credentials is one thing they can't do; they're pretending to be you, and you don't hash your banking passwords, so they can't.)

Using Mint, then, increases risk. You must work out if that increased level of risk is acceptable to you. If it is not, then you have to take action to decrease the risk, which is pretty much going to mean not using Mint.


Regarding smartphones, are applocks with a 4 digits pin less secure than those with a 50 digit pin? I want to install an applock to my android phone. I have found a great one, but its only drawback is that is supports only 4 digits pins, whereas other similar apps support with maybe 10 or more.

I know in password setting, the more chars the merrier. But is this the case with applocks? do 4-digit pins offer a reasonable level of security? And if yes, under which case?

From a technical point of view 4 digit pins alone (I.e with no attempt restriction / timed lockout) offer no security at all. They can be brute forced in under a second on any vaguely modern device. Saying that in this case the difference is of more or less no benefit.

Security is about far more than key entropy. You should realise against a technical opponent every app locker I've seen for android or IOS offers zero security benefit. The underlying data is still just as accessible - it's basically just stopping you launching the shortcut.

What are you trying to defend against?

If you're hoping to stop a skilled opponent (law enforcement, determined criminal etc) from accessing certain applications I would suggest you look for a better strategy than an app locker.

If you're trying to stop your mum, child or friends from posting to your Facebook  when then have your phone for two minutes to view a photo I'd argue that they are unlikely to make it past an entirely random 4 digit number assuming no related technical skills and Googling "How to get around [name of app locker] doesn't yield anything useful.


OpenPGP master key with certificate and authentication capabilities (on a smartcard) After researching about OpenPGP and smartcards, I came to a dilemma. The usual setup I've seen more widely is a master key (with SC capabilities) and 3 subkeys (with S, E, A each):

pub  4096R/0E427716  created: 2016-01-15  expires: never       usage: SC
                               trust: ultimate      validity: ultimate
sub  2048R/49C9CBD7  created: 2016-01-15  expires: 2016-10-12  usage: S
sub  2048R/A7D84FFD  created: 2016-01-15  expires: 2016-10-12  usage: E
sub  2048R/879F1ED3  created: 2016-01-15  expires: 2016-10-12  usage: A

I understand the concept of keeping the master key only for the purpose of signing and certifying subkeys. The problem comes when trying to write the keys to a smartcard which only have three keys/subkeys slots, as I want to write master key inside the card.

Is it going to work and still be safe adding authentication capability to the master key 0E427716 then writing it to the smartcard along with only two subkeys (one for signing 49C9CBD7 and one for encrypting A7D84FFD)?

For clarifying the final picture in the smartcard will be:

pub  4096R/0E427716  created: 2016-01-15  expires: never       usage: SCA
sub  2048R/49C9CBD7  created: 2016-01-15  expires: 2016-10-12  usage: S
sub  2048R/A7D84FFD  created: 2016-01-15  expires: 2016-10-12  usage: E

I'll keep three backup smartcards in safe places, so don't worry, no way to lose the master key.

I wouldn't go for it. This means additional exposure of the master key, and it might have been exposed in bugs like CVE-2016-0777 when used with SSH.

You can also not distinguish any more between using the primary key vs using a subkey.

If you're going to buy several cards anyway, and are keen on using a card for the primary key, buy another one (or set of cards) and put the primary key on a dedicated card (set). This will not only enable you to be sure about which key you're going to use (the primary key is not connected at all), but also remove the three-keys-limitation of OpenPGP smartcards.


How eval() in php can be dangerous in web application's security? I want to know that How eval function can be dangerous for any web application's Security?

Below is the code I use to understand when any user input passes to the eval function, then How an attacker can exploit it?

<?php

$x = @$_GET['arg'];

eval("\$y = \"$x\";");
echo $x;

?>

Ok, first imagine that I send this request:

script.php?arg=foo

Your eval then looks like this:

$y = "foo";

But if I send this:

script.php?arg=";%20echo%20exec('whoami');%20//

This turns your code into this:

$y = ""; echo exec('whoami'); //";

Which executes the "whoami" command on the server and prints the result. The // comments out the end part of your original code so it gets ignored and my code runs successfully.

This is an incredibly trivial remote code execution bug to exploit.


HMACSHA512 versus Rfc2898DeriveBytes for password hash We are currently using HMACSHA512 in .net, with a 128Char (64byte) validation key
The salt is 64 char randomly generated string.
We allocated 2048 length on the database for the hashed base64 string result.
It will be a public facing website.
Is this approach reasonable or should it be changed to another approach such as Rfc2898DeriveBytes?

 public string HashEncode(string password, string salt, string validationKey) {
        byte[] hashKey = BosUtilites.HexStringToByteArray(validationKey);
        var sha512 = new HMACSHA512(hashKey);
        var hashInput = BosUtilites.StringToByteArray(password + salt);
        byte[] hash = sha512.ComputeHash(hashInput);
        return Convert.ToBase64String(hash);
    }

 public string GenerateSimpleSalt(int Size = 64) {
        var alphaSet = new char[64]; // use 62 for strict alpha... that random generator for alphas only
        //nicer results with set length * int i = 256. But still produces excellent random results.
        //alphaset plus 2.  Reduce to 62 if alpha requried
        alphaSet = "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890#=".ToCharArray();
        var tempSB = GenerateRandomString(Size, alphaSet);
        return tempSB.ToString();
    }

    public StringBuilder GenerateRandomString(int Size, char[] alphaSet) {
        using (var crypto = new RNGCryptoServiceProvider()) {
            var bytes = new byte[Size];
            crypto.GetBytes(bytes); //get a bucket of very random bytes
            var tempSB = new StringBuilder(Size);
            foreach (var b in bytes) { // use b , a random from 0-255 as the index to our source array. Just mod on length set
                tempSB.Append(alphaSet[b%(alphaSet.Length)]);
            }

            return tempSB;
        }

EDIT2: In case Someone finds this via google, I have included the lessons learnt
Average sample in tests on workstations was around 300 msecs. This should not be too noticeable during logon.  And no more need for a Validation key. Which is a relief :-)

 SCrypt package installed via nuget. and rfc2898 PBKDF2 changed to be large number or iterations but only 20bytes output.  SAme CPU time.

New passwords are encoded in SCRYPT by default,

  <package id="CryptSharpOfficial" version="2.0.0.0" targetFramework="net451" />
  // save salt, hash algorithm used and resulting encoding on user record
  public string PasswordEncode(string password, byte[] salt, HashAlgorithm hashAlgorithm ) {
        switch (hashAlgorithm) {
            case HashAlgorithm.PBKDF2:
                    var deriver2898 = new Rfc2898DeriveBytes(password, salt,<Use a number around 50K>); // approx 300msecs on workstation
                    byte[] hash = deriver2898.GetBytes(20); //
                    return Convert.ToBase64String(hash);
            case HashAlgorithm.Scrypt:
                var key = Encoding.UTF8.GetBytes(password);
                byte[] hashScrypt =  SCrypt.ComputeDerivedKey(key: key, salt: salt,
                                    cost: 65536, // must be a power of 2 !, on PC, singlethread this is approx 1 sec
                                    blockSize: 8,
                                    parallel: 1,
                                    maxThreads: 1,
                                    derivedKeyLength: 128);

                    return Convert.ToBase64String(hashScrypt);
            default:
                throw new ArgumentOutOfRangeException("hashAlgorithm");
        }
    }

Rfc2898DeriveBytes implements PBKDF2: a function which turns a password (with a salt) into an arbitrary-length sequence of bytes. PBKDF2 is often used for password hashing (i.e. to compute and store a value which is sufficient to verify a password) because it has the needed characteristics for password hashing functions: a salt and configurable slowness.

These characteristics are needed because passwords are weak: they fit in human brain. As such, they are vulnerable to exhaustive search: it is feasible, on a general basis, to enumerate most passwords that human users will come up with and remember. The attack assumes that the attacker got a copy of the salt and the hashed password, and then will "try passwords" on his own machine. That's called an offline dictionary attack.

In your case, you have a third element: a validation key. It is a key, i.e. supposedly secret. If the attacker could grab the salts and hashed passwords but not the validation key, then he cannot perform the dictionary attack on his own machines; under these conditions (the validation key remains secret, and the validation algorithm is robust -- HMAC/SHA-512 is fine for that), the configurable slowness of PBKDF2 is not needed. This kind of validation with a secret key is sometimes called "peppering".

Note, though, that when we assume that the attacker could grab a copy of the hashed passwords, then it becomes a matter of delicacy to suppose that the key remained unsullied by his vile glances. This depends on the context. Most SQL injection attacks will be able to read part of all of the database, but not the rest of the files on the machine. Nevertheless, your server must somehow be able to boot up and start without human intervention, so the validation key is somewhere on the disk. An attacker stealing the whole disk (or a backup tape...) will get the validation key as well -- at which point you are back to the need for configurable slowness.

Generally speaking, I would recommend PBKDF2 (aka Rfc2898DeriveBytes in .NET) over a custom construction, although I must say that you appear to use HMAC properly (homemade constructions rarely achieve that level of correctness). If you insist of having a "validation key" (and you are ready to assume the procedural overhead of key management, e.g. special backups for that key), then I suggest using PBKDF2 and then applying HMAC on the PBKDF2 output.

See this answer for a detailed discussion on password hashing.


php- is my code secured enough to protect from remote command execution when using shell_exec()? I am using shell_exec function on the following variables to execute commands on the shell:

fname (characters only)
fpack(characters only)
email (a valid email address)

My code is:

<?php

require_once 'connectionToDB.php';

$fname = mysqli_real_escape_string($dbc, filter_var(escapeshellarg($_POST['fname']), FILTER_SANITIZE_STRING));
$fpack = mysqli_real_escape_string($dbc, filter_var(escapeshellarg($_POST['fpack']), FILTER_SANITIZE_STRING));
$email = mysqli_real_escape_string($dbc, filter_var(escapeshellarg($_POST['email']), FILTER_SANITIZE_EMAIL));

/** Verify name of applicaion **/
if(!ctype($fname)) {
    $op = json_encode(array('type' => 'error', 'msg' => 'Application name must be in english alphabetical letters only'));
    die($op);
}
if(strlen($fname)>20) {
    $op = json_encode(array('type' => 'error', 'msg' => 'Application name must be less than 20 characters'));
    die($op);
}

/** Verify name of package **/
if(!ctype($fpack)) {
    $op = json_encode(array('type' => 'error', 'msg' => 'Package name must be in english alphabetical letters only'));
    die($op);
}
if(strlen($fpack)>20) {
    $op = json_encode(array('type' => 'error', 'msg' => 'Package name must be less than 20 characters'));
    die($op);
}

/** Verify user's email **/
if (strlen($email)>50) {
    $op = json_encode(array('type' => 'error', 'msg' => 'Email must be of less than 50 characters'));
    die($op);
}

if (!filter_var($email, FILTER_VALIDATE_EMAIL)) {
    $op = json_encode(array('type' => 'error', 'msg' => 'Please provide a valid email address.'));
    die($op);
}

As I said I am using shell_exec on these variables, I am scared of remote command execution. Is my code safe enough to prevent RCE?

No, this is not secure.

Most of the code doesn't even make sense. It looks like you've simply thrown all functions you know at the variables in the hopes that this will somehow help. That's a very poor approach. Not only does is not work; it actually introduces bugs and may lead to severe problems.

Neither MySQL-escaping nor HTML-filtering (through FILTER_SANITIZE_STRING) have anything to do with the shell. SQL, HTML and the language used by your shell are three entirely different contexts and require entirely different security procedures. You cannot randomly combine them. For example, mysqli_real_escape_string() will break the quoting of escapeshellarg() and may indeed enable the user to manipulate the shell command.

Also note that most of those functions you're using are destructive, which means they silently change the data entered by the user. This is a very bad idea, because you may end up executing commands which the user never wanted you to execute. Either accept or reject the user input, but do not silently replace it with something else.

So you'll need a very different approach:

Validate the raw user input. If it's not acceptable, stop and throw an error.
Then prepare the input for the specific context you want to use it for. In the case of shell arguments, only use escapeshellarg() to properly escape the input for shell contexts.


Can Asymmetric encryption be used instead of modern authentication strategy? Assuming that I have a way to associate a combination of public private key encryption with real people/user. The private key is stored on the device of the user.

User have to communicate with some web service on multiple hosts for load balancing. Each host can verify the correctness of this key by calling a function.

Each client encrypt and sign with his key every request (that is tunnelled https anyway) and server always verify the signature and that the key is still trusted.

I mean to protect some CRUD request by verifying every request based on asymmetrical encryption. I’m thinking to use some encryption library. Application on the server receive the request and before processing the requests, It verify the digitally signature of the payload of http requests.

Can I rely only on this scheme for authenticate and accept request from the user?
Or I have to add one additional layer of authentication such user/password or oauth2?

I believe, you want a two-way authentication, when TLS server identifies and authorizes clients based on client certificate information. In fact, it is already implemented and is called mutual TLS authentication. See for "client certificate authentication in TLS" queries. For example, this article provides a good explanation of mutual TLS authentication: https://blog.cloudflare.com/introducing-tls-client-auth/

When properly implemented, there is no much need to implement additional authentication mechanisms as long as you can distinguish uinque clients based on their certificates (e.g. map certificate to a particular user account in users database). Microsoft IIS has a built-in mechanism to authenticate and map client certificates to SAM or Active Directory users and no username/password mechanisms are necessary.


Apache Settings to Secure Files In the past I have used two methods for securing files for web apps.

Put them outside of webroot (which is usually {www || http}/app). So files would usually be stored outside apache altogether.

OR

Restrict access within my .htaccess file

My friend suggested another alternative which is similar to option 1 but allows all files to remain together. He suggested that when setting up my virtual host I adjust the path to {www || http}/app/public.
This option would allow me to store all related files in {www || http}/app and just store all private files in {www || http}/app/private
Should there be any concerns with this method?

Answer from @SteffenUllrich

This is exactly the same as option 1 only with a different webroot and
thus it provides the same security.


What are the most frequent ways someone's password "leaks"? List of user:hash published? Same password for web and local (os...)?
Phishing?

Phishing, dictionary and social engineering based approaches are far more frequent than database leaks.

Database leaks result in far more passwords being released than via the above approaches because a large scale leak can result in hundreds of millions of passwords being released.

However - why are you asking? For example if concerned about your own credentials assuming secure practices are used by the service a user can protect themselves from database leaks and dictionary attacks by using a secure unique password. I.e. your username, hash pair can leak without the underlying password being revealed. Sophisticated phishing and social engineering can be harder to protect against at the individual level.


Does Metasploit's packet sniffing run in promiscuous mode? I'm doing an educational pen test exercise and I'm trying to sniff traffic from a compromised Windows machine.  I've been using the post-exploitation sniffer and packetrecorder Meterpreter modules, but so far, they've only contained packets either destined for the host I'm using or broadcast traffic.  I'm trying to figure out if I'm missing some data or if there isn't any other traffic on the subnet.

Do either of these modules run in promiscuous mode?

To answer whether the sniffer module runs in promiscuous mode by default I am doing a test in my lab right now and will update it here when its done.

UPDATE

The answer finally comes out to be YES. The sniffer module does its capturing in promiscuous mode.
To test I set up a win-xp-sp2 (10.10.10.101) vm on proxmoxVE (kvm virtual env). I added it to a bridge and added kali-linux (having ip 10.10.10.15) and a few more machines (machine-a 10.10.10.100 and machine-b 10.10.10.110) to the bridge. After running the exploit for netapi, I started the sniffer module on the target. Problem is linux bridges act as switches by default so again I ran into the same problem. I could only see the machines own traffic and broadcasts. Now to make a linux bridge act like a hub and not a switch, the aging for the bridges mac address table needs to be set to 0 (so it doesn't have a mac-address-table at all and traffic like broadcasts seding it to all members. For reference the command is brctl setageing <bridgename> 0. Once this was done, I pinged from machine-b to machine-a and here is what I got:

2013-08-28 21:22:03.000000 ARP, Request who-has 10.10.10.100 tell 10.10.10.110, length 46
2013-08-28 21:22:03.000000 ARP, Reply 10.10.10.100 is-at 2e:76:03:d3:b9:72, length 46
2013-08-28 21:22:03.000000 IP 10.10.10.110 > 10.10.10.100: ICMP echo request, id 11328, seq 1, length 64
2013-08-28 21:22:03.000000 IP 10.10.10.100 > 10.10.10.110: ICMP echo reply, id 11328, seq 1, length 64
2013-08-28 21:22:04.000000 IP 10.10.10.110 > 10.10.10.100: ICMP echo request, id 11328, seq 2, length 64
2013-08-28 21:22:04.000000 IP 10.10.10.100 > 10.10.10.110: ICMP echo reply, id 11328, seq 2, length 64
2013-08-28 21:22:08.000000 ARP, Request who-has 10.10.10.110 tell 10.10.10.100, length 46
2013-08-28 21:22:08.000000 ARP, Reply 10.10.10.110 is-at 22:06:8c:52:9f:c5, length 46

As you can see none of the above is supposed to be seen by the xp2 vm apart from the ARP who-has packets. Hence I can safely say that all packets which somehow reach the interface being sniffed are indeed recorded by the sniffer module and it is definitely running in promiscuous mode.

General but important Information

Switches send packets destined to IPs which you have an ARP entry on remote hosts for only. The remote host will send the packet with a destination MAC address based on their ARP table and a switch will only send it out the port where that MAC address is located. So even in promiscuous mode you will only see packets either explicitly destined to your IP or broadcasts which are sent out all ports connected to the switch in the same collision domain (VLAN and subnet).

Hubs on the other hand mirror data received from anywhere to all ports irrespective of the destination MAC address since they are not smart enough to know which port the destination MAC address is available on. This leads to traffic between other machines also getting sent to you and this is probably the case you were hoping for, but from what you described the virtual switch acts like a semi-intelligent switch with a MAC table and the behavior is as described in the first paragraph.


Is 1password vulnerable to NSA spying? In light of the recent heartbleed vulnerability, I'm thinking of switching to a service like 1Password.  However, I don't know how to evaluate the risk of NSA (or other government) spying.  So, two questions: how can I evaluate the risk of such spying, and is 1Password secure from it?

EDIT: I thought it went without saying, but I'm interested in answers that explain the rationale used.  I'm not interested in baseless opinion about 1Password (like "1Password sucks!"), but I am interested in impartial criticism, with an emphasis on how one can evaluate services like it with respect to this vulnerability.  Also, please back up any opinions with facts and references.

EDIT 2: I realize that asking for definitive proof of spying is unrealistic.  I'm asking for a way of evaluating the risks.  For example, if they claimed to be free of government spying, that would be useful information.  (They make no such claim, as far as I can tell.)  Or perhaps it is significant that they are a Canadian company.  I don't know, and I would appreciate help from you security experts.

If some three-letter agency is after you, personally, then you are doomed. They already put a microphone in your home, maybe even a video camera with a good view on your screen and keyboard.

If the same three-letter agency does its job properly (and you should hope for it, since it is paid with your tax money), then knowing whether they bribed any given online service cannot be answered: a positive answer, one way or the other, would be a proof of incompetence of the said agency.

In any case, what makes you believe that a random guy on the Internet like me would be trustworthy ? There is no way that your question may find here an answer that you can count upon. Be rational in your paranoia !


Is the Web browser status bar always trustable? If I bring the mouse pointer to a link, but not click on it, I can see in the left/bottom corner that it displays the URL of it.

Q: Could this URL (in the left/bottom) be different from the one that my Web browser will go? (don't count that server side can be redirected with an eg.: HTTP 302)

Question is just because of knowing that telling the users to check the left/bottom of the browser before clicking on the link is a good/usable thing regarding security.

Please provide authentic links/descriptions too :)

PS: maybe if JavaScript is enabled, it can be done that the user will go to another website, different from the one displayed in the left/bottom?

UPDATE: Does disabling JavaScript with ex.: NoScript solves this problem 100%? (opened a bounty for this part of the question) - because it looks like it could be prevented with NoScript.

Could this URL (in the left/bottom) be different from the one that my webbrowser will go?

Yes.

for a simple link click, the whole click could be captured by JavaScript and made to do something else, including navigating to a different page
the link could be substituted onmousedown (this is common behaviour for some link-click tracking scripts)
for browsers like Chrome where the address pop-up appears inside the page area, that pop-up could be faked with JavaScript and page elements. In general you can only trust browser UI that appears in the chrome border, outside of page control.

Consequently the address pop-up is a convenience feature but offers no security function.


TLS and e-mail security Our client has asked us to send sensitive data via TLS and to install a certificate on our mail servers so that they can verify the authenticity of our e-mails.

If I understand correctly, TLS encrypts the 'tunnel' that the message is communicated through, while not encrypting the actual content of the e-mail or any of its attachments. Is this correct?

If this is the case, am I right in saying that the content of the e-mail is potentially vulnerable to being intercepted at any server that is involved in SMTP relay between our outbound mail server and the recipients mail server?

TLS is just for connection authentication or as you called it, the "tunnel".  It's really just for mail flow connections between servers and/or clients to make sure that unauthenticated clients/servers aren't permitted to send mail through said host/server.
If they want you to install a certificate on your server, that's for the purpose of verifying that there isn't a rogue or spoofing mail server trying to send them mail using your domain name but not your server.  It's one of many ways to verify the sending server's authenticity to send mail for the respective domain.
Encryption of the email data itself is a completely different technology.  There are various third-party vendors that offer this service, along with open source options such as PGP


When generating a 4096 bit RSA key pair, do both the private and the public key always have exactly 4096 bits? When generating a 4096 bit RSA key pair, do both the private and the public key always have exactly 4096 bits, thus do not start with a 0 in binary representation?

As a preliminary, in RSA the public key is the pair (N, e) and the private key is d. Like it has been stated, the bit size of the modulus N is what the 4096 refers to. N only makes up part of the public key, along with e. There is no requirement for what bit size e is. The only requirement for secure encryption in RSA is that exponentiating the message m to the eth power "wraps the modulus", i.e. m^e > N. So in practice values of e as small as 3 (2 bits) have been used. The most common current value for e is 65537 (17 bits) in fact most SSL certs that you see have this value e.g. google.com

The bit size of d, the private key, is not set and can vary greatly as it is simply the multiplicative inverse of e in the group phi(N) where phi is the totient function. In most cases it will be much smaller than 4096 bits.


How can I securely generate secret-sharing/multisig keys on a p2p network? I am trying to create a peer-to-peer escrow system. I need to encrypt the private key of a wallet with a 2-of-3 secret-sharing function - the buyer, seller, and arbitrator will each have have one key.

The problem lies in the generation of secret keys on a p2p network, as there is no trusted server. What can I do to prevent a maliciously modified client from making a copy of the keys before distributing them to their rightful owners?

Thanks in advance!

If buyer, seller, and arbitrator are all using the same client and are all "peers", where peers are potentially untrusted and might use a malicious client, there is no one person to trust.

Also, the premise of having one client generate 3 keys and distributing them to others, and then deleting them is a weak premise. The client need only find one way of not deleting an item and this premise falls.

Another option might be to just encrypt something for each of the other 2 using public keys.


Linkedin spam through Skype - how to check if I am infected? I am following on this question:
What risks do I have now that I accidentaly opened a suspicious URL send to me by Skype?
Since I am new, I cannot comment on this thread hence the new question ...
I also saw this thread and this one but did not find an answer.

So, dumb me clicked on https://www.linkedin.com/slink?code=dZxV84r#16501=myskypeusername for whatever reason. Thing is, I did not get redirected to other websites but ended up on a linkedin page saying something like "Oops, this link is broken".

I ran several full system scans with Avast free and Malwarebytes free that found nothing fishy. Am I safe to assume that I was fortunate enough not to catch something ? If not, can you guys guide me through further tests ?

Many thanks, Oberom

Unless Linkedin site is compromised or vulnerable to Open Redirections, XSS or CSRF you should be fine.

For better practice when opening suspicious links you can download sandbox browser that will isolate and protect your PC from infection.

http://www.sandboxie.com/


Track an Android phone through its IMEI My mobile phone got stolen few days back. I tried all possibilities to track it, the only option is through IMEI. Can I know which SIM card is running on that specific IMEI?

It is very possible to identify the SIM based on the IMEI if the phone is powered on, and on the network. The problem is that you most likely do not have access to this information unless you work for the carrier, and typically these guys don't care about your stolen phone enough to disclose this information. Sorry for your loss and good luck.


How to prevent buffer overflow attack? int main(void) {
    char buff[15];
    int pass = 0;
    printf("\n Enter the password : \n");
    gets(buff);
    if (strcmp(buff, "thegeekstuff")) {
        printf("\n Wrong Password \n");
    }
    else {
        printf("\n Correct Password \n");
        pass = 1;
    }
    if (pass) {
        /* Now Give root or admin rights to user*/
        printf("\n Root privileges given to the user \n");
    }
    return 0;
}

i know I have to change pass so it wont allow a non-zero value to get through but how do i do that?

gets() does not limit its input, it is impossible to use securely.

I'd suggest to use

fgets(buff,15,stdin);

instead of gets.

Other solutions may exist.


What are the risk tradeoffs of all-in-one "smart" IDs vs. using a separate hardware authenticator? In many organizations these days, employee IDs are very mutli-functional.  They can serve as:

Visual identitiy verification.  (Including employee photo, name, ID number, and other details on the face)
Building access control.  (Via RFID, prox card, bar code, magnetic strip, or smart chip)
Computer access control.  (Smart chip)
Encryption & digital signature certificate storage.  (Smart chip)

All of these functions can be conveniently packed into one card, no larger or thicker than a common credit card.  However, it may be more practical to some if the latter two functions were separated.  Instead of a completely all-in-one solution, perhaps they could have one badge used as their visual ID and building access control, and another badge (or other hardware authenticator) used for certificate storage and computer access control.

What would be the risk tradeoffs between these?

WRT to smart card being used as an authentication factor for computer access, the private key on the smart card can be protected by a PIN/password.  So the smart card auth can also provide the additional factor of "what you know" in addition to "what you have."

For most users, the risks are acceptable when compared to the cost of managing provisioning/distribution and operation of multiple sets of physical authentication tokens.  I've seen people in different organizations and consultants carry around a chain of smart cards and usb tokens for the various organizations they are consulting for.  Granted, offering a service provider model for identity management is still a while away, there's a trend to offer simpler auth models (i.e. outsourced second factor auth, openid, hoth, etc).

For higher risk users or locations, I often see additional factors for authentication.  For example, three factor is fairly common (biometric, card, pin, weight).  In addition, I've worked with organizations where I only need to present a card + biometric in a mantrap during business hours but after business hours, I also need to use an additional factor.  In addition, high risk users usually are subject to additional segregation of auth keys versus signing keys.  So, there's a second device used to contain a non-repudiated signing key to authorize certain transactions.

Organizations and users with very sensitive information leverage additional controls that sacrifice simplicity and speed for security.  Even a simple mantrap takes longer to auth a user than turnstyle.

With that said, organizations that consolidate all functions are usually larger in size with multiple physical locations.  Such organizations can realize cost savings by consolidating into one vendor, one card, etc.  Though I'e seen more small-medium organizations go the route of consolidated access control, they are few and far between (password's are still common and by far, cheaper than implementing hardware auth).

If anything, security 101 includes a long blurb and discussion on defense-in-depth.  Consolidating functions don't necessarily open up more risk as long as risk is identified and managed.


How to exploit HTTP Methods Many security scanners like nikto, nessus, nmap, and w3af sometimes show that certain HTTP Methods like HEAD, GET, POST, PUT, DELETE, TRACE, OPTIONS, CONNECT, etc are vulnerable to attack.
What do these methods do and how can they be exploited?
I'm looking something more creative than common exploits like POST or GET injections (e.g., changed fields). It would help me to understand if your answer showed me a brief example of the normal usage of the header as compared to an exploit technique of a header.

Some of these methods are typically dangerous to expose, and some are just extraneous in a production environment, which could be considered extra attack surface. Still, worth shutting those off too, since you probably wont need them:

HEAD, GET, POST, CONNECT - these are completely safe, at least as far as the HTTP Method itself. Of course, the request itself may have malicious parameters, but that is seperate from the Method... these are typically (note exception below) the only ones that should be enabled.
PUT, DELETE - as mentioned by @Justin, these methods were originally intended as file management operations.
Some web servers still support these in their original format. That is, you can change or delete files from the server's file system, arbitrarily. Obviously, if these are enabled, it opens you to some dangerous attacks.
File access permissions should be very strictly limited, if you absolutely MUST have these methods enabled. But you shouldn't, anyway - nowadays, there are simple scripts you can use (if this is a static website - if it's an actual application, just code it yourself) to support this feature if you need it.
NOTE: One valid scenario to enable these methods (PUT and DELETE) is if you are developing a strictly RESTful API or service; however, in this case the method would be handled by your application code, and not the web server.
OPTIONS - this is a diagnostic method, which returns a message useful mainly for debugging and the like. This message basically reports, surprisingly, which HTTP Methods are active on the webserver. In reality, this is rarely used nowadays for legitimate purposes, but it does grant a potential attacker a little bit of help: it can be considered a shortcut to find another hole.
Now, this by itself is not really a vulnerability; but since there is no real use for it, it just affects your attack surface, and ideally should be disabled.
NOTE: Despite the above, OPTIONS method IS used for several legitimate purposes nowadays, for example some REST APIs require an OPTIONS request, CORS requires pre-flight requests, and so on. So there definitely are scenarios wherein OPTIONS should be enabled, but the default should still be "disabled unless required".
TRACE - this is the surprising one... Again, a diagnostic method (as @Jeff mentioned), that returns in the response body, the entire HTTP Request. This includes the request body, but also the request headers, including e.g. cookies, authorization headers, and more.
Not too surprising, this can be substantially misused, such as the classic Cross-Site Tracing (XST) attack, wherein an XSS vector can be utilized to retrieve HttpOnly cookies, authorization headers, and such. This should definitely be disabled.
One other set of Methods bears mentioning: ALL OTHERS. For some webservers, in order to enable/disable/restrict certain HTTP Methods, you explicitly set them one way or another in the configuration file. However, if no default is set, it can be possible to "inject" additional methods, bypassing certain access controls that the web server may have implemented (poorly). See for example some more info on OWASP.


Software security V.S Hardware security In theory, perfect software applications are possible but in real life, they don't exist. When attackers know the software, they can send payloads to exploit vulnerabilities and run any arbitrary code they want remotely. On the other hand, we have HSM (Hardware security modules), for example we program smart cards to execute basic codes (e.g cryptographic algorithms) which is attack free without physical access to chip.  Questions:

Is it possible to use a chip based system -as cheap as raspberrypi- and make it run complex codes -maybe a basic browser- to check emails without worrying about malicious code?
Is it possible to create a compiler which randomizes codes -maybe a browser on netbsd- to execute functions in many different ways for each user so when attackers discover vulnerabilities on public code, they can't exploit users who have random compiled versions?

Hardware security modules

Running code in a physically-protected chip such as a HSM or a smartcard is not about protecting from software bugs. If there's a software bug in a HSM, it can be exploited just as any webserver, laptop, smartphone, whatever. The difference between a HSM and a PC is that with physical access to a PC, you can just boot from a USB stick or swap out the disk. With physical access to the outside of an HSM, you still have to break in, and HSMs are designed to self-destruct when you make a serious attempt at opening them.

Running a browser on a Raspberry Pi

A PC is a “chip-based system” as much as a Raspberry Pi. There's no fundamental difference between them: a Raspberry Pi isn't somehow “more secure” than a PC.

More people use PCs, so PCs are a more valuable target to exploit, so more people try to exploit PCs. PCs also have a heavy burden of historical compatibility and a large variety of software, which puts them somewhat more at risk. But if people routinely ran browsers on Pis instead of Pentiums, there'd be more exploits out there for Pis.

Moving the browser to a different machine isolates it. But what do you gain? A lot of exploits are delivered through the browser. Often the browser itself is the target. It has access to the network, so it's a valuable target to spread the infection to other machines. It's how the user interacts with a lot of things, so it's a prime target for thieves and scammers. No matter where you put your browser, if it's infected, you've lost.

Randomizing code

Randomizing code in some way is a defense technique, but it only makes exploits harder, it doesn't make them impossible.

For example, some modern operating systems practice address space layout randomization: each time a program starts, it's loaded at a different random address. This means there are things you can't do in an exploit, such as refer directly to the address of a piece of code in the original program. It doesn't make exploits impossible: there has to be a way the program can find its own pieces (for example, a short relative jump will keep working just fine), and if some piece is hard to find the exploit can search for it (it's a common issue even without ASLR because often the exploit code itself will be loaded at an unpredictable address).

Randomizing code in the compiler wouldn't buy you much, and it's expensive. All these forms of randomization make debugging harder. If you randomize before distributing the program, you have to manage the distribution and maintenance (updates) of all these different versions. And security-wise the benefit it minimal because in the end the program still has to do the same thing.

How hardware helps with security

For run-of-the-mill systems (not HSMs and the like), the role of the hardware is to enforce isolation between components. It's a hardware component, the MMU, that makes it impossible for a program to directly access another program's memory. The CPU design also makes it impossible for ordinary programs to directly access hardware peripherals, they have to go through operating systems interfaces for that. The hardware has to be used correctly: it's up to the operating system to set up the MMU tables correctly and so on.

You can't put too much intelligence into the hardware. The more you do, the more there's a risk that there'll be a bug in your design. Hardware bugs are pretty hard to fix. So the hardware provides some basic capabilities, and the complexity is handled in software as much as possible.


Web Service Security Checklist - Tracing and Debugging I have been reading this security checklist about web service design:

http://msdn.microsoft.com/en-us/library/ff648304.aspx

One of the suggestions is that you should disable the following in production environments:

1) Tracing

2) Debugging

Now I know that both tracing and debugging are used to study the flow of the program in order to find bugs so that these can be fixed.

I know that these two should be disabled because they would greatly hamper the performance of the server.

However, if these are not disabled, do they present security risks?  For example, is tracing information still displayed on the client's computer or is it displayed only on the server's computer?  What about debugging information?

Yes, production servers should present little information outside their designed purpose to the outside world. Display of any kind of debug or trace information (intentional or accidental) could clue hackers/attackers into where to pinpoint an attack, a particular form box that maybe vulnerable and at the very least make finding a weakness in your site less difficult, and in the worst case open up a front door to any hacker familiar with the system/software should a noteworthy bit of information show up in the debug listing.

Production code is always recommended to run with debug and trace code turned off.

On the flip side it will make finding internal bugs more difficult if you are not doing internal checking and logging of errors, this is why you type check, argument count, length check, etc etc prior to running your code on untrusted data (from the outside world).

Failure to check your data is how hackers have bagged so many buffer overflow bugs and easily entered into many sites remotely. Should your checks detect something out of the ordinary then an internal log (not accessible to the outside world) should be generated and a email sent off to the administrator to indicate that the log needs checked but no indication of a problem should be made to the outside world, this is to avoid alerting a hacker of a potential goldmine, instead continue the process like everything is normal even if you don't actually process the data, the hacker will write it off as nothing interesting.


How secure are TOTP codes? I was wondering about the security of TOTP codes.

Is there any cryptographic security around the secret to stop a user being able to guess the secret after capturing a variety of TOTP codes. For example:

Attacker sniffs creds on a targets network where SSO is over HTTP using User:Pwd:TOTP . After some time can the attacker make a reasonable guess as to what the TOTP secret is by looking at what secrets produce each TOTP code and narrowing down the results?

Yes, TOTP is cryptographically secure. TOTP is HMAC of current timestamp using a shared secret [1]. HMAC is secure. TOTP produces only 6 digits (20 bits), while protocols like TLS prefer longer MACs (128 bits), but there is no way to predict the next TOTP code (with better than 1 in 10^6 odds) by seeing all previous TOTP codes, without knowing the shared secret.

1 - https://en.wikipedia.org/wiki/Time-based_One-time_Password_Algorithm


Are PGP's public and private keys a two-way street? I understand that in PGP a public key encrypts and a private key decrypts. Is it possible to encrypt a message with my private key and have the recipient decrypt it with my public key?

I know that this would provide no real security since my public key is widely known. It would also be a very impractical way of establishing that I authored the message since PGP already supports signing. I'm just curious about whether it's possible to encrypt and decrypt both ways.

First of all: it depends. There are cryptographic algorithms that can be used both ways like RSA, but also others that can only be used for encryption or signing (in OpenPGP, those usually occur in pairs, like DSA for signing together with an ElGamal subkey for encryption).

  Is it possible to encrypt a message with my private key and have the recipient decrypt it with my public key?

In the case of RSA, signing a document technically is equivalent to encrypting the hash sum of the document with your private key; if a third party can decrypt it with your public key, the document must have been encrypted by your private key (and given you did not hand that out, it was encrypted by you).

Other encryption algorithms like ElGamal cannot be used like this, on the other hand signing algorithms lika DSA cannot be used for encryption.

  I know that this would provide no real security since my public key is widely known.

It would of course not provide confidentiality,  but also authorship can be considered security!

  It would also be a very impractical way of establishing that I authored the message since PGP already supports signing.

Considering OpenPGP specifically: If you create an RSA primary key that has both signing and encryption capabilities set, you actually use the same public/private key pair for both encryption and signatures as you described. In GnuPG, you will have to provide the --expert flag while creating the key. Doing so is discouraged, though; splitting duties might prevent some (yet unkown) attacks at least for some usage of your key/key set.


Can someone take down my mobile data connection? I have a friend who says that he can take down anyones mobile data connection and one day he did it while I was in the tram with him. Is it possible that someone can DDOS your mobile data connection, or hijack it or something?

I already answered this for WiFi.

Please read my cleaned-up version of this if you're less interested in how WiFi and cellular networks compare here, but in only the attack surface.

A lot of the things said there still apply here, I'll reduce the list to the ones that also apply to GSM/other mobile network standards:

  Physical layer attacks: Simply jam the frequency spectrum with your
  own signal. That signal might just be noise, but it might also be a
  WiFi network base station of your own under heavy load, with the nodes in that WiFi mobile network being
  configured not to play nice with others. (depending on the WiFi mobile terminal
  chipset, that can be extremely easy) Spectrum can only be used once!
  Tool: noise source (e.g. Gunn Diode, SDR device), or normal AP
  Electromagnetic sledgehammer: EMI gun. Take microwave oven
  oscillator, attach directive antenna, pray you don't cook someone's
  (your) brain, and point in the rough direction of the access point.
  Poof!
  Tool: Microwave oven, some sheet metal, lack of regard for other people's property and own health, or extended RF knowledge
  MAC and Network layer attacks: Especially for networks using WEP A5/1 (noone should
  be using this anymore, but sadly...) it's easy to forge what is called
  deauthentication packets – and thus, to throw out stations from your
  WiFi. decrypt GSM calls and fake base station knowledge
  Tool: Aircrack-NG's aireplay SDR+software base station, or hardware base station, or modified phones.
  Targetted jamming: As opposed to simply occupying the channel with noise or your own WiFi mobile network, you can also
  build a device that listens for typical WiFi packet's beginnings
  (preambles), and then, just shortly, interferes. Or just sends fake
  preambles periodically, or especially when it's silent. That way, you
  can corrupt selected packets, or fake channel occupancy.
  Tool: Commodity off-the shelf SDR
  authentication attacks: at some point, even "proper" clients for your WiFi mobile network need to register with
  the WiFi mobile network. That mechanism can of course be forced to its knees by
  simply sending hundreds of authentication requests every second, from
  randomly generated MAC addresses hardware IDs/IMEIs, or even from MAC addresses of
  clients you know (by observation) exist. There's no solution to the
  problem for the AP base station – either it succumbs to the overload of auth network registration
  packets requests, or it starts blocking out legitimate users.
  Tool: your network card a cheap mobile phone under your hardware control, 10 lines of bash scripting
  Man-in-the-Middling / access point base station spoofing: With anything short of
  WPA(2)-Enterprise, nothing proves that the access point calling itself
  "Toduas AP" is actually your Access Point. You might have heard of "Stingrays". If not, google is your friend. Simply operating a slightly
  higher-powered access point base station with the same ID string and, if necessary
  at all, a faked AP MAC address (trivial, since just a setting) operator identity, will
  "pull" clients away from your access point real network. Of course, if the spoofing
  Access Point base station doesn't know the password secret keys of the network operator(only necessary if >2G), users might quickly notice (or
  they don't); however, noticing things don't work is nice, but
  doesn't help them.
  Tool: a random normal access point any implementation of a base station. They're not expensive.

  You have to realize that it's a privilege, not a right, to have your
  WiFi use a channel. WiFi happens in the so-called ISM bands
  (Industrial, Scientific, Medical usage), where operators of
  transmitters don't have to have an explicit license. That means it's
  OK for everyone to use that spectrum, as long as they don't
  intentionally harm other devices and are not easily damaged by
  interference.

  So, it's absolutely legal for someone to operate a high-definition
  digital camera stream that occupies the whole WiFi channel. That will
  effectively shut down your WiFi.

Of course, it's illegal to interfere with mobile network operation. Illegality doesn't mean impossibility or a high probability of legal consequences for the attacker.

  If you need something that no-one can mess with, wireless is, by
  definition, not the way to go.


Any ways to protect my user data on company computers? I have a desktop computer at work running Windows 8.1 Pro. For logging in I use a domain account and I have logged in with my Microsoft account to get access to my Onedrive and syncing of email accounts and such things. I'm the only one using the computer.

Everything works the way I want, but I'm wondering a bit about security in relation to my personal data. I assume for example that IT can log on with an administrator account and access all my files being synced via Onedrive (probably even though most of them are online-only?), and even though I don't think they will do that I would of course prefer if they couldn't. There's also the fact that when I stop working here at some point, someone might take over this computer and I don't trust them to wipe it first. I'll probably make an attempt to do it myself when that time comes, but still.

Are there ways I can protect my own user data on a company computer from snooping IT workers? Especially looking for solutions that come built-in with Windows and are as transparent as possible. And by transparent I mean that it shouldn't cause a lot of problems when I'm using it like messing up Windows in any way, having to enter special credentials a lot, etc.

I assume enabling BitLocker on the system drive is one thing one could do, but wouldn't really help against people logging on with other domain admin accounts?

Administrator is your God. You don't fight your God; you appease Him with offerings and grovelling worship.

Your potential attacker can perfectly install some keylogger/screenlogger on your machine, get everything you type, see everything you see, get a copy of everything you download or upload. Basically this is not your machine. Technically, the machine "belongs" to the Administrator, and you are just a guest. Don't try to fight him; he has all the technical power to defeat you utterly.

Of course there are regulations and laws against IT people snooping on people's files. However there probably are clauses in your employment contract that more or less directly allow the employer to scan your data, since the computer is the company's computer, not really yours. So while active snooping is improbable if the IT people are like most IT people (i.e. their natural nosiness is more than balanced by their inherent laziness), an industrious IT admin with loose morals and some Internet-fueled competence can perfectly eavesdrop on everything you do on that computer without you getting the slightest warning about it, and without leaving incriminating traces.

It would be safer for you to simply bring your own laptop, connected to the Internet through your smartphone, and accessing your personal data from that computer only.

This situation has an amusing twist. You are thinking of your computer as "yours" and trying to protect your personal data from the company that owns the hardware. You see the company as a potential attacker. Be assured that the reciprocal is true: most "IT security teams" see the user (i.e. you) as the attacker. When they tell you that such and such system or procedure is enforced "for security", don't be a fool: they mean "for security against the user himself".

While this shared mistrust is of course detrimental to actual security of the data (against outsiders), it is still widespread and, to a large extent, self-powered. IT security teams fight against users because they see users as troublemakers that will look for ways to evade their scrutiny and, for instance, use the company resources for personal usage, and indulge in non-work-related dangerous behaviours (like downloading malware-riddled applications). Users do that because they don't trust IT security teams, as your own question shows. Of course, both the users and the IT people think that the other party is a bunch of morons.


What are criteria and rules to determine bug bounty amounts? How is the reward amount determined on different bug bounty platforms like Bugcrowd, HackerOne or Synack?
As a bug bounty program owner I can maybe define some rules for the rewards. What are the common, established rules and how do the different platforms support them?

Criteria to determine bounty amounts
A bug bounty program's rules should communicate the used criteria and process for determining bounty amounts as clearly as possible. However, bug bounty platforms usually don't constrain your program's reward structure or enforce fixed severity levels which you must adhere to. There are just too many cases that require some flexibility. That said, many program rules lay out tables of different tiers with baseline (and possibly maximum) payouts. The following are some common criteria to rank vulnerability submissions and determine adequate amounts.

Severity of the vulnerability. A more severe vulnerability should (obviously) pay more. A remote code execution bug is most likely more dangerous than XSS and so on. You can apply the Common Vulnerability Scoring System (CVSS) to quantify the severity of a given security bug. However, this may get tedious. Many program rules just set a rough list of tiers. E.g., Google's VRP distinguishes between remote code execution, file system/database access, security control bypasses, client-side code exec (e.g. XSS), and others. Similarly, the program of Uber makes use of several "security impact buckets".

Relevance of the affected application/component. This partially ties into the previous point. The same type of vulnerability may have a different impact on different sites or components. XSS on a static subdomain served over HTTP may not be as harmful as XSS on the main domain where users manage their accounts. As for a real-life example, Twitter's program distinguishes vulnerabilities affecting the Twitter core (e.g. on *.twitter.com) from all others. Google's VRP classifies applications as account management-related, high severity, normal, and non-integrated/lower priority applications, each with their own payout structure.

Maturity of the bug bounty program. A new program/scope should start with moderate bounties and increase payouts once the "low-hanging fruits" have been discovered and finding high-severity bugs becomes increasingly difficult. You should keep adjusting baseline amounts based on the reports you're receiving to pay fair bounties that balance the bug hunters' skill and time efforts, with your budget.

Quality of the report. Some programs pay higher rewards for well-written reports. This is especially common/relevant for client software where some bugs can be significantly easier to investigate and patch with more technical information and post-report assistance by the researcher. E.g., Mozilla's Client Bug Bounty Program states "Improving test cases post-submission, figuring out if an engineer's speculation is founded or not, or other assistance that helps resolve the issue will increase your bounty payout." However, for your standard reflected XSS in a web app, a simple proof of concept is often sufficient and a submission quality rating has no merit.

Broader context of the bug. Sometimes, a vulnerability submission has an impact beyond the initial report. It may reveal a larger issue or be more critical than the researcher anticipated. Or, on the contrary, multiple reported vulnerabilities may all have the same root cause and it makes sense to treat them as a single bug. These considerations may, too, warrant a payout adjustment.

(Some of these points are presented similarly in the SANS whitepaper Bug Bounty Programs: Enterprise Implementation, chapter 2.7. Also have a look at #2 of this instructive post on the HackerOne blog.)
Assigning bounties on a bug bounty platform

...how do the different platforms support them?

Platforms generally let vendors choose the bounty amount freely. E.g. on HackerOne you can choose between pre-calculated amount levels or reward a custom amount.

(Image: HackerOne Docs)
HackerOne also provides an optional CVSS calculator which can be used to have a vulnerability's severity determined automatically.
The right bounty range to start with
... depends on the budget your company is willing to assign to the program. As mentioned above, you can start with low bounties and work your way up based on the reports received and bounties paid so far. It may help to look at the payout ranges of other companies that are comparable to your own business. The concrete financial considerations would be beyond this answer.


Is safe to store passwords in Android/iOS App own storage? I'm creating an app that logins to a remote API that doesn't implement oauth2 or another similar mechanism, and I want to know if is reasonably safe to assume that password will be safe if is stored in app private storage like Shared preferences or SQLite?

OWASP, an org that provides guidance to app developers, has a few reference material:

The original Mobile Top Ten 2012 Insecure Data Storage reference -- https://www.owasp.org/index.php/Mobile_Top_10_2012-M1
The updated Mobile Top Ten 2014 Insecure Data Storage reference -- https://www.owasp.org/index.php/Mobile_Top_10_2014-M2
An iOS Developers Cheat Sheet which makes specific suggestions about where to store what types of data, when it is required of an app's functional tasks -- https://www.owasp.org/index.php/IOS_Developer_Cheat_Sheet#Insecure_Data_Storage_.28M1.29

For Android, I might suggest using secure-preferences instead of the Shared Preferences you suggested, or perhaps cwac-prefs. Check out examples of these in the book Android Security Cookbook.

On iOS, be sure to read the iOS Application Security book, which recommends Lockbox to store data in the Keychain, as well as methods to add and remove credentials. If you're building an iOS mobile app, this book is highly-recommended.

If you don't like or for some reason can't use Lockbox (or just want to try different options), then check out this idea from the book, Mobile Application Penetration Testing:

  Utilize the different options provided by Apple, as we learned in the
  section Keychain data protection in Chapter 2, Snooping Around the
  Architecture. You can also utilize one of the simple wrapper
  PDKeyChainBindingController
  (https://github.com/carlbrown/PDKeychainBindingsController) to secure
  the keychain data. However, if the device is jailbroken then keychain
  information is not secure. It is recommended to use custom encryption
  techniques to encrypt the string that is stored in the keychain. Make
  the best use of the keychain services API
  (https://developer.apple.com/library/mac/documentation/Security/Conceptual/keychainServConcepts/01introduction/introduction.html).

The book also covers another issue related to credential storage in the Keychain:

  On June 18, 2015, a password stealing vulnerability, also known as
  XARA (Cross Application Resource Attack), outlined for iOS and OS X
  cracked the Keychain services on jail broken and non-jail broken
  devices. The vulnerability is similar to the cross-site request
  forgery attack in web applications. In spite of Apple's isolation
  protection and its App Store's security vetting, it was possible to
  circumvent the security controls mechanism. It clearly provided the
  need to protect the cross-app mechanism between the operating system
  and the app developer. Apple rolled out a security update week after
  the XARA research. More information can be found at
  http://www.theregister.co.uk/2015/06/17/apple_hosed_boffins_drop_0day_mac_ios_research_blitzkrieg/

and provides details on the Keychain itself, should one utilize a jailbroken device to attempt to get access to it

  Keychain in an iOS device is used to securely store sensitive
  information such as credentials, such as usernames, passwords,
  authentication tokens for different applications, and so on, along
  with connectivity (Wi-Fi/VPN) credentials and so on. It is located on
  iOS devices as an encrypted SQLite database file located at
  /private/var/Keychains/keychain-2.db


How can I really change the IP address? I am from Serbia. When I visit Facebook or Instagram with my VPN (Avast) on and location set to Japan, the pages are still in the Serbian language.

When I change location to Japan I guess it should display in Japanese language? It look slike they can somehow detect VPN and see the real IP address.

Is there a way I can really change my IP address?

One of the primary things used for websites to determine which language to send the page back in is the Accept-Language header.  Modern browsers set this header for all requests based on your preferred language settings.  It is probable that even though you are using a VPN with an IP address in Japan, your browser is still sending the Accept-Language header with a preference for Serbian


Is it bad practice to ask only for individual characters of a password? Some financial websites that I use use passwords in a peculiar way. Instead of asking me the whole password string, they only ask me to enter e.g. "3rd, 5th and 8th character of your password", i.e. a random combination of characters of the password string.

I think this would make sense if it's done using a shared random number table etc. But this is a password. In order to do this, they'd have to either store my password without hashing, or store the hashes for all the combinations they want to ask, which also sound bad. Am I right to think that this is a fairy bad security practice?

You are basically right; this is poor practice, for several reasons:

As you note, it requires server-side storage of the password as plaintext or in some reversible format.
Typing a password repeatedly works on "muscle memory", which allows the user to "remember" his password as a sequence of gestures on the keyboard; asking for specific letters exercises distinct parts of the brain and is likely to induce dangerous behaviours, i.e. writing down the password.
If the site asks for only three characters, then an attacker has a fair chance of gaining access by simply responding with three random letters. Online dictionary attacks can work, too. (Of course, bank Web sites often couple that with a trigger-happy lockout system, but a smart attacker will switch to another target account before reaching the autolock limit.)

The three main reasons why bank sites do that are:

If they ask for only three letters, not always the same, then a key logger or shoulder surfer won't be able to immediately his illegitimately acquired knowledge. It can be thought of as some sort of damage containment, where the password is only partially divulged.
Asking for only some letters is an Hollywood-sanctioned security measure. It makes for a great show. Customers, being unaware of what information security really entails, will see that and think "wow, that's secure !".
Many people in the industry are no less impressionable than average customers. Quite a few "security architects" will see such a system and also think "wow, that's secure !".


How long should a email confirmation code be to avoid brute forcing Let's say we want to new users to confirm their email address on a secure website (one that we don't want users making fake accounts impersonating other users). For UX reasons we may want:

Short as possible codes in case user types it in
alphanumeric codes for easy typing
Does not require user to re-enter their email address when confirming the code

A code that is too short is vulnerable to brute force attempts to confirm it. For example the code 1234 could be easily guessed. The attacker just registers target@example.com and then spams verification codes until hitting the target (and may verify many other random emails).

There's a number of strategies to fight this including:

Use a long code that can't be guessed - perhaps forcing the user to click a verify link instead of typing it in manually
Expire code relatively quickly - giving the attacker less time
Force the user to identify who they claim to be by either logging in or typing their email before the confirmation code. Then expire the code after X attempts. This forces the attacker to have to constantly restart their guessing - removing possibility for an exhaustive search. However it's potentially a UX papercut. Maybe a user clicks the confirm email on a phone after signing on with their desktop. The phone would require logging in and is a slight barrier to sign up.
Make use of capcha, rate limiting, or other strategies to deter automation. This is probably not guaranteed to solve the issue alone.

Each strategy can potentially harm the UX however. What is a reasonable balance of UX without compromising security?

Provide a URL with a long identifier, user not having to login, and a short 4-digit code, where the user has to log in, and limit to for instance 5 attempts per 24hr.

And it's not like it's hard to get an e-mail account today, so it's of limited overall value.


What is the main risk of allowing services to logon as NT AUTHORITY\SYSTEM? Many enterprises run service on production servers as SYSTEM without considering the risk that might arise from this configuration, what is the biggest risk associated with it? and how would attackers exploit this kind of configuration?

Worst case scenario

When an attacker exploits an application to run arbitrary code then this code will run under the context (and thus the privileges) of the exploited application. So if the service running as SYSTEM has a listening port and is exploitable from the internet or network then the attacker can do pretty much anything on the computer, including adding new administrator accounts or dumping passwords and certificates using mimikatz

Privilege escalation

If the application isn't listening on a port, or isn't exploitable using that port, then the service might still allow the attacker to elevate privileges. this requires the attacker to have some lower privileged access first, like through exploiting a lower privileged application or user.

To attack the service this way the attacker usually needs to look for misconfigurations in the service itself, rather than the application. He can try to edit the binary (exe file) of the application and then restart the service, try and edit the path of the service (thus editing what exe is executed when the service boots up). Or he can try DLL hijacking just to name a few.

If one of these attacks succeed, he can run code in context of the application and thus as SYSTEM. To minimize this risk, run applications on the least amount of required privileges possible, if the service doesn't need to run a SYSTEM then doing so poses an unnecessary security risk.


Man in the middle attack, bridging wlan interface to virtual wired interface at0 I'm trying to execute a Man in the Middle attack on my mobile phone, I have two wireless cards, one inbuilt in the laptop, running AR9285 atheros drivers, the 2nd is an Alfa AWUS036NHA card with an AR9271 driver. I'm using the alfa card (wlan1) to create a virtual router with the following commands:

$ airmon-ng start wlan1
$ iwconfig wlan1 channel 5
$ iwconfig mon0 channel 5
$ airbase-ng -e FreeWiFi -c 5 mon0

All this seems to work, an AP is created and I can attempt to connect to this with my phone, and it displays something along the lines of "Obtaining an IP address".

$ ifconfig at0 up

Above I bring up the at0 interface, I've tried this assigning an IP as well (0.0.0.0), also with a valid IP (e.g. x.x.x.next_available_number), and neither seems to work. I've also tried applying an address to wlan0, the wireless interface connected to the internet, this doesn't seem to work and also prevents me from getting internet connection.

$ brctl addbr m
$ brctl addif m at0
$ iw dev wlan0 set 4addr on
$ brctl addif m wlan0

Above I create the bridge and add both the interfaces, wlan0 is not usually usable in the bridge without the iw command. Next I bring up the bridge, at this point do I assign the bridge an IP address, the bridge interfaces, both, or neither? I've tried many variations and none seem to work:

$ ifconfig m up

OR

$ ifconfig m x.x.x.x up

The final step (as I understand it), is to run DHCP on the bridge. I try to do this with the following command:

n$ dhclient m

This program usually takes some time to run, and provides absolutely no output. At one point it asked me to install a package 'phonon-backend-gstreamer', which I did. But it still does not work.

If I look on the phone it says 'Obtaining IP address', in wireshark, on at0, I see a few DHCP requests and ARP broadcasts, however eventually the phone gives up and says something like 'Avoided bad internet connection'.

So, are there any obvious steps I have missed out, or perhaps something is being done in an incorrect order? Let me know if anything is not clear, thanks in advance!

The problem is clear! you don't have a DHCP server to provide an IP to the mobile phone.

You have two solutions:

Make sure that your Wlan0 is connected to a network with a DHCP server, 'for example: your home network', so when you make the bridge the phone will have an IP.
install a DHCP server apt-get install dhcp3-server and configure it to provide IPs.

Either ways, you forgot an important thing to do, make your system to re-forward the packets using the command:
echo 1 > /proc/sys/net/ipv4/ip_forward


What are the alternatives to ECDSA for an authentication protocol? In an authentication protocol, S has a public/private key pair known to C, and S and C have established a secure channel (for example, using DH or ECDH, or any other key exchange protocol). C wishes to determine whether the peer over this secure channel possesses the private key.

In ECDSA, the key pair is an elliptic curve key pair, and the signature algorithm uses the DSA scheme (DSS) with the elliptic curve. The DSA scheme is known to have some undesirable properties -- weaknesses in the RNG are a real concern, considering that an attacker can obtain a million signatures.

If authentication only is required, we don't need a fully-blown signature scheme (ie, the ability to sign arbitrary messages is not required). What alternative schemes could be used which avoid the scary property that re-use of the identification key in multiple signatures will eventually leak it?

One simple scheme follows:

C uses IES to encrypt a nonce N1, and sends this to S (this is the elliptic curve integrated encryption scheme).
S then sends HMAC(key=Z, N1) back to the C, where Z is a shared secret obtained via the key exchange phase (remember, we've already established a shared channel using DH or some other method).

This proves possession of the private key: the private key is required for S to have obtained N1 from EIS(N1). The server is not a decryption oracle -- it doesn't decrypt arbitrary messages on behalf of C, but rather replies with the HMAC of the decrypted value. Finally, because the shared secret Z was mixed in, which was jointly determined by C and S, the signature can't be used to perform a man in the middle attack: someone wishing to impersonate S to C is sent by C the encrypted N1, but can't forward it to S for signing, because the signature is tied to the channel's Z.

Question

Does my dead-simple scheme have a name? Is it weak? It appears to avoid the DSA problem where multiple signatures may eventually reveal the key, but I haven't done all the algebra to be sure!
What are the popular standard solutions to the problem? FHMQV is patented, sadly, but it's designed exactly for this situation, isn't it. I guess the popular solution appears to be ECDSA (used in TLS, SSH), which I'd hope to avoid.

Remarks

Menezes' article "elliptic curve signature schemes" in the "Encyclopedia of Cryptography and Security" lists DSA, Schnorr, Nyberg-Rueppel as the various known elliptic curve signature schemes. DSA is the one I don't like, and Nyberg-Rueppel apparently has exactly the same weakness as DSA (two signatures using nonces with any known bits in common leak private key information). Schnorr signatures look good, but they don't seem to be widely used.
Hugo Krawczyk's HCR (Hashed Challenge-Response, based on XCR, Exponential Challenge-Response) looks very promising too -- it's a beefed-up version of Schnorr that is supposed to be more robust. I think it's covered by Patent EP1847062B1 though, which expires around 2025 apparently.

In answer to question 2, you could use RSA instead for the signature algorithm. While people are moving to ECDSA due to it being faster, there's nothing inherently wrong with RSA still.


How can I set up DHCP so that domain devices get a certain block of IP addresses and other non-domain devices get a separate block? Is there a way for me to set up DHCP so that only domain devices get an IP Address from a certain subnet, say 192.168.12.x, and other non-domain devices would be assigned to a different subnet?

Edit: I'm currently running Windows Server 2008.

DHCP on its own isn't capable of this. YaRi's answer doesn't do anything to separate the networks - if you plug a non domain system in to a domain assigned VLAN port you would be on the wrong network.

You could maintain a list of MAC addresses for your domain systems and base your ranges on this (if you aren't in the list, you aren't included in the domain IP range).

If you are serious about this what you really need is a device designed for network access control and supporting the 802.1x protocol. That is probably overkill.