With an IPS in place, do we really need firewalls? I was reading the article "Do you need an IDS or IPS, or both?"
 on TechTarget. While reading the author's explanation of IPS this question hit me.

If an IPS is a control tool that uses a set of rules for blocking/allowing traffic and a router can route and NAT and implement ACLs, then what is a firewall good for?

The terms "Firewall" and "IPS" do not describe specific technical implementations and capabilities. While traditionally the term "Firewall" is mostly used to describe a stateless and then later a stateful packet filter (like Checkpoint Firewall-1) they are also used to describe proxy based technologies (like the FWTK - firewall toolkit). And what was formerly was called IPS is today (more or less enhanced) marketed as Next Generation Firewall (NGFW). Note that the article you refer to seems to be from 2009 when the term NGFW was still uncommon.

If you look at the underlying technologies: a traditional IPS was commonly implemented with deep packet inspection (DPI) but additionally a packet filter was used (i.e. one of the traditional meanings of the term "firewall") to reduce load on the DPI in that  obviously unwanted or wanted connections were handled by the packet filter firewall in a cheap way instead of dealing with these in the way more resource-hungry and slower DPI.


I receive spam despite a captcha, has my wordpress blog been hacked? I have a wordpress blog under my own domain. It does not have special security.

For the past 1 week, my blog got spammed by someone from Russia - I think the contents of my blog somehow angered him. He posts about 20 spam comments (only links to drugs, etc..) daily  at staggered hours. I just can't understand. Comments need to enter name, email and also to pass a "captcha" graphics verification. It would be extremely boring and tedious to do such spamming manually. In general comments cannot be done through automated software unless some expert hack into my site.

Does anyone know if it is likely someone is able to hack into my site?

Posting spam doesn't require hacking in any ways.

Regarding the captcha, there is two possibilities:

Either the captcha is automatable (I don't know for your website, but I still encounter a lot of websites bearing completely useless captchas).
If the captcha is not automatable, then spammers can hire people to solve them for as low as $2 for a thousand captchas.

Your website is usually not specially targeted: they just target any random URL where comments are directly published. When possible, prefer to avoid automatically publishing visitors comments but publish them after moderation, at least ensure that the rel="nofollow" property is used for links in comments so spammers websites doesn't gain any reputation by posting links in your comments section.


Is it possible to get virus/malware by just connecting to an Android phone acting as a WiFi hotspot? Is it possible that my Windows 8.1 computer gets infected by virus or malware by just connecting to an Android phone acting as a WiFi hotspot? I didn't do anything else. I didn't surf the internet, nothing. I just connected to it. I know chances are, everything is okay, but I also want to know if my thinking is right or not.

I don't use an anti-virus software. I just monitor what's going in and going out.

Is it possible for an Android device to send something bad to a Windows computer just by connecting to it?

Yes, a WiFi Hotspot is a proxy which has the means to perform many acts including malicious ones. Be it an android phone acting as a WiFi hotspot or a router or any other devices.

  Passive

  Snoops on your traffic, data credentials like passwords etc.

  Active

  Redirect you to malicious links resulting you in downloading malware
  or pushing malware to your device.

There are known trojan that can perform malicious acts via a hotspot and there are countless more unknown (it's a guaranteed).

It is the unknown that we are unsafe from. So the best thing is to connect only to a WiFi hotspot that you know and are familiar with.

Last but not least, do you want to apply the two second rule here? Drop a donut on the ground, pick it up in less than two seconds; ok cool. No bacteria, I can eat it.

In this case, just connecting for that split second and then disconnecting does not mean you're safe. Data similarly can be ex filtrated in that few seconds.

Better safe than sorry, recent years of leaks show just how vulnerable we are in security and privacy.

Some research here

Commercial Surveillance Tools Being Used as Mobile Malware
Xsser mRAT Targets iOS and Android for Man-in-Middle Attacks
Smartphone infections double, hotspots are also a trouble area


What are methods for preventing browser hooking / drive-by downloads? This question may be a bit too broad and open ended, however I'm hoping to get some good advice on this.

With the advent of BeEF and more and more of the computers in networks being infected just by going to websites, I wonder what effective methods there are to mitigate such risks besides keeping your browser up to date, using noscript, OS updates, etc.

Keep your system up to date,  but that is obvious and wouldn't help you with the IE 0-day last month.

The majority of browser based exploits require JavaScript in some capacity. NoScript helps mitigate these attacks.

The Google Safe browsing API is used by Firefox and Chrome by default to prevent you from reaching a site that is known to be leveraging browser based attacks.  However this does nothing for a targeted BeEF attack.

Some Anti-Viruses will plug into your browser and prevent an exploit from loading.  This could prevent a targeted BeEF attack.  But AV's aren't perfect and can be fooled.

Plan on failure, consider doing most of your day to day browsing inside a VM.  Restore this VM to a virgin state on a regular basis (once a week,  or once a month).  Assume that you have been compromised and change your passwords regularly.


New to ossec - what does active response do out of the box I am new to ossec.  I installed the server and wui on a dedicated machine.  I have agents running on my zookeeper and kafka servers to start.

Below are events I am seeing.  I assume the are automated bots.

10 - User missed the password more than one time
10 - Multiple SSHD authentication failures.
5 - SSHD authentication failed.

So....one IP address is 222.186.62.17

So...did ossec ban the IP address?  Is there anything I have to do to enable ossec to ban 222.186.62.17?  Or enabled by default.

What about port scanning e.g. those that use nmap?  Will they be banned?

I am looking for what works out of the box for protection via active response.

With OSSEC ver. 2.7.1, ossec.conf (by default located in /var/ossec/etc) contains the following active response configuration:

<!-- Active Response Config -->
<active-response>
  <!-- This response is going to execute the host-deny
     - command for every event that fires a rule with
     - level (severity) >= 6.
     - The IP is going to be blocked for  600 seconds.
     -->
  <command>host-deny</command>
  <location>local</location>
  <level>6</level>
  <timeout>600</timeout>
</active-response>

<active-response>
  <!-- Firewall Drop response. Block the IP for
     - 600 seconds on the firewall (iptables,
     - ipfilter, etc).
     -->
  <command>firewall-drop</command>
  <location>local</location>
  <level>6</level>
  <timeout>600</timeout>
</active-response>

So any active OSSEC rule that fires with both a severity >= 6 and successful identification of the source IP will trigger the temporary blocking of the IP address (600 seconds by default).  This is assuming you answered yes to the following server installation question:

  Do you want to enable active response? (y/n) [y]:

In ossec-local.conf, you can see the active command dependencies (i.e. "expect = srcip"):

<command>
  <name>host-deny</name>
  <executable>host-deny.sh</executable>
  <expect>srcip</expect>
  <timeout_allowed>yes</timeout_allowed>
</command>

<command>
  <name>firewall-drop</name>
  <executable>firewall-drop.sh</executable>
  <expect>srcip</expect>
  <timeout_allowed>yes</timeout_allowed>
</command>

In /var/ossec/rules/syslog_rules.xml, you can find the rule that generated the User missed the password more than one time alert:

<rule id="2502" level="10">
  <match>more authentication failures;|REPEATED login failures</match>
  <description>User missed the password more than one time</description>
  <group>authentication_failed,</group>
</rule>

The rule definition above has a level (i.e. severity) of 10, so that should trigger the temporary IP block.

In /var/ossec/rules/sshd_rules.xml, you can find the rule that generated the Multiple SSHD authentication failures alert:

<rule id="5720" level="10" frequency="6">
  <if_matched_sid>5716</if_matched_sid>
  <same_source_ip />
  <description>Multiple SSHD authentication failures.</description>
  <group>authentication_failures,</group>
</rule>

Again, the above rule definition specifies level 10, so that should trigger the temporary IP block.

In /var/ossec/rules/sshd_rules.xml, you can find the rule that generated the SSHD authentication failed alert:

<rule id="5716" level="5">
  <if_sid>5700</if_sid>
  <match>^Failed|^error: PAM: Authentication</match>
  <description>SSHD authentication failed.</description>
  <group>authentication_failed,</group>
</rule>

The above rule definition specifies level 5, so this rule would not trigger the temporary IP block.

Port scanning with nmap will result in a temporary IP block based on this OSSEC rule (i.e. 10 connection attempts within 90 seconds, level 10 alert):

<!-- Scan signatures -->
  <group name="syslog,recon,">
    <rule id="40601" level="10" frequency="10" timeframe="90" ignore="90">
      <if_matched_group>connection_attempt</if_matched_group>
      <description>Network scan from same source ip.</description>
      <same_source_ip />
    </rule>
</group> <!-- SYSLOG,SCANS -->


What is the relationship between "SHA-2" and "SHA-256" I'm confused on the difference between SHA-2 and SHA-256 and often hear them used interchangeably (which seems really wrong).  I think SHA-2 a "family" of hash algorithms and SHA-256 a specific algorithm in that family.

Is that correct?  Can someone please clarify?

Just to cite wikipedia: http://en.wikipedia.org/wiki/SHA-2:

  The SHA-2 family consists of six hash functions with digests (hash values) that are 224, 256, 384 or 512 bits: SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224, SHA-512/256.

So yes, SHA-2 is a range of hash functions and includes SHA-256.


What's the point in hashing phone numbers? Some services (for instance ProtonMail) claim to store hashes of phone numbers, instead of phone numbers themselves (while they don't say how they hash it). Now, given that the number of potentially valid phone numbers is very small (about 26 bits worth of information in an 8-digit phone numbers), it should be quite easy to recover a phone number from its hash.

So what's the point?

ProtonMail may request your phone number to perform a human check:

ProtonMail detects that you're attempting to create several accounts.
It requests you a phone number, to send you a token via SMS.
You must send that token to ProtonMail to prove you're the phone number owner.

Then, ProtonMail doesn't need your phone number anymore, but it still need to use it to prevent spammers to create multiple accounts.

Hashing the phone number allows it to not store the original number and to prevent someone to use the same number twice.

From their FAQ:

  However, using the same phone number will result in obtaining the same cryptographic hash, so by comparing hashes, we can detect re-use of phone number or email addresses for human verification.

Thus ProtonMail doesn't seem to use unique salts.

We also know thanks to a tweet from Bart Butler (ProtonMail CTO) that:

ProtonMail regularly flushes stored hashes.
Stored hashes aren't linked to any account.

Bart Butler also tweeted:

  We use a slow password hash (With a salt) and flush the list and rotate the salt at irregular intervals.

In conclusion: brute-forcing them is possible, but it's neither practical nor useful.


Rootkits, Bootkits detection and protection and Firmware alteration I was hacked in an extremely intrusive manner in late 2013. Ever since then, not a day has passed where I don't think about this. A lot. My question has to do with the likelihood of the attackers having altered my BIOS so they would have persistent access to my information, even if I wiped the hard drive(s) and changed operating systems, which I did. (I've been learning about Linux ever since) I believe this is referred to as either a rootkit or a bootkit. Along those same lines, how difficult would it be to alter the firmware on my Android(s) in order to guard against Factory Data Resets? Finally, how can I detect some of these attacks having been performed on me?

Thanks

If attackers had administrator/system/root level privileges on your computer, they have a lot of possibilities to permanently backdoor your computer. Not many attackers can do this kind of persistence, but it is possible.

MBR bootkit - can be cleaned via formatting from live cd
BIOS/UEFI malware - see Computrace rootkit
HDD firmware - GrayFish malware
GPU/Ethernet/other firmware modification
Hardware implants

The best solution is to box all of your devices which has more than 0% chance of infection (and label the box with something like "infected, don't use"), and buy a new computer and a new phone - but don't order it to your home, go and buy one in a random local store. And don't trust any of your old data from old backups. Based on your paranoid level, not even image, music, video files can be trusted - but it is 99% they are safe. MS Office documents can be a risk more likely.

I believe the same attacks are more or less possible on Android devices, but there are no known cases of these - at least I know of. I think the easiest backdoor would be to replace the bootloader.

Detecting such intrusive rootkits are hard. There is no simple way to check for rootkits. The easiest way to do this is to disable the services on your computer which communicate with the internet until nothing should communicate, and run tcpdump on your router for days. After that, analyse the traffic and look for unknown IPs/domains. Meanwhile, check for side channel leaks like WiFi or Bluetooth. Most rootkits can be found via this method. Creating fake activity (e.g. typing in a text editor, generating new fake PGP keys) might help trigger the bad traffic.
When it comes to rootkit detection on Windows, my personal experience is that GMER can find most rootkits - but not all.


After How Much Data Encryption (AES-256) we should change key? Considering AES-256 encryption, what is the maximum amount of data should be encrypted with one key? Does Block cipher modes/IV/counters also governs the limit?

If say the maximum amount is 50GB, does it mean the one file of 50GB has limit or 5 files of 10GB?

A block cipher is a Pseudorandom permutation: the key selects the function seemingly at random in the set of possible permutations of the space of block values (that space has size 2128 for the AES, since it has 128-bit blocks). Most usages of a PRP are fine as long as it looks like a Pseudorandom function. The difference between a PRP and a PRF is that the PRP will never give you two identical outputs for two distinct inputs, whereas the PRF may do so. However, a randomly selected function will give you such a collision only out of random, and it will require a lot of invocations: on average, 2N/2 invocations if processing blocks of size N.

Translation: when you encrypt more than 264 blocks with AES (i.e. 268 bytes, since an AES block is 16 bytes), AES begins to look more like a PRP than a PRF, and that's the point where you should stop. That's more than 250 millions of terabytes, which is quite a substantial amount.

It does not matter whether the said amount of data was processed as one, ten or 42 billions of whatever you may elect to call a "file". The AES processes blocks of 16 bytes and knows nothing else. On the other hand, it does not matter at all, since you will not practically reach that 268 bytes limit: AES was defined with 128-bit blocks precisely so that we could encrypt terabytes of data without worrying about a key running out of juice. When AES was specified, it was meant to replace 3DES, whose 64-bit block size was indeed worrying (232 blocks of 8 bytes, that's 32 gigabytes, which can be reached quite easily on today's machines).

Key size has nothing to do whatsoever with that matter. It is all about block size, and that's 128 bits for AES (regardless of key size).


Is a constant pepper at risk if an attacker knows the value and hash? My app is a educational game for elementary schools, involving no money or anything of value, so I am not worried about sophisticated attackers having any interest in this. Still, I would like to follow best practices in case any of this code ever does wind up guarding something attractive.

The security consists of hashing values with a constant pepper to produce a hash. Generally, the values are things like the user id and other state info, and hash is used to preventing tampering (i.e., so you can't change the user id to a different value and access someone else's data).

Therefore, over time, the attacker has access to a large set of state info (the pre-hash) AND the hash, but not the pepper. The hash algorithm is also server-side and unknown (though limited in possibilities).

With this knowledge, can an attacker determine the pepper and hash algorithm and be able to generate a suitable hash for any message, breaking our security?

This could be ok depending on the implementation, but it could also easily go wrong. An attacker would be unable to recover the pepper (assuming it has enough entropy), and they would be unable to hash arbitrary values.

However, your peppered hash is likely vulnerable to a length extension attack. If an attacker knows some data and its hash, this would allow them to append data while still being able to calculate the new hash as if they knew the pepper. To prevent this, instead of using the secret as a pepper, use it as the key for an HMAC. Even if you aren't worried about length extension attacks this is desirable, as it provides more security properties with no downsides, and it sounds like a MAC is what you're really after.


First steps in preventing DOS attacks My server is currently being attacked from another server. This is my log:

root@my-server:/var/log# tail -f auth.log
Feb 19 11:53:08 my-server sshd[3745]: Disconnecting: Too many authentication failures for root [preauth]
Feb 19 11:53:08 my-server sshd[3745]: PAM 5 more authentication failures; logname= uid=0 euid=0 tty=ssh ruser= rhost=125.32.114.181  user=root
Feb 19 11:53:08 my-server sshd[3745]: PAM service(sshd) ignoring max retries; 6 > 3
Feb 19 11:53:39 my-server sshd[3747]: Address 125.32.114.181 maps to 181.114.32.125.adsl-pool.jlccptt.net.cn, but this does not map back to the address - POSSIBLE BREAK-IN ATTEMPT!
Feb 19 11:53:41 my-server sshd[3747]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=125.32.114.181  user=root
Feb 19 11:53:44 my-server sshd[3747]: Failed password for root from 125.32.114.181 port 1680 ssh2
Feb 19 11:53:57  sshd[3747]: last message repeated 5 times
Feb 19 11:53:57 my-server sshd[3747]: Disconnecting: Too many authentication failures for root [preauth]
Feb 19 11:53:57 my-server sshd[3747]: PAM 5 more authentication failures; logname= uid=0 euid=0 tty=ssh ruser= rhost=125.32.114.181  user=root
Feb 19 11:53:57 my-server sshd[3747]: PAM service(sshd) ignoring max retries; 6 > 3

What are the first steps in preventing such kind of attacks?

Considering the attacker's doing full tcp-ip handshakes, installing a HIDS like OSSEC or fail2ban should work quite nicely to automatically drop this traffic.


In this example why do they hash a randomly generated piece of salt before hashing it with the password? From here, in the code return substr(sha1(mt_rand()),0,22); what is the point of taking the sha1 value? It is appended to the password and together they are hashed using Blowfish.  Why not just append the randomly generated number?

class PassHash {
    // blowfish
    private static $algo = '$2a';
    // cost parameter
    private static $cost = '$10';
    // mainly for internal use
    public static function unique_salt() {
        return substr(sha1(mt_rand()),0,22);
    }
    // this will be used to generate a hash
    public static function hash($password) {
        return crypt($password,
                    self::$algo .
                    self::$cost .
                    '$' . self::unique_salt());
    }
    // this will be used to compare a password against a hash
    public static function check_password($hash, $password) {
        $full_salt = substr($hash, 0, 29);
        $new_hash = crypt($password, $full_salt);
        return ($hash == $new_hash);
    }
}

They do this hashing out of a mixture of insecurity and shamanism.

The hashing has no value for actual security. Their salting is bad because mt_rand() is not sufficient to ensure uniqueness (good salts should strive to be unique, and random salts are a good way to get unique values with high probability, but it requires the use of a good random generator, in a sufficiently large space of value; and mt_rand() fails at both). Hashing the output of mt_rand() with SHA-1 gives the impression that the salt is more random than it really is; the developers must have the warm fuzzy feeling that things are safer since they "look random" to their human eyes.

Also, sprinkling hash function invocations on a given piece of code is a way to propitiate the Spirits of Cryptography. It is well-known that crypto deities look favourably upon those who use them a lot (or so many developers believe, apparently).


Work with user tokens and sessions I am trying to develop a social media app and website. The problem is I am trying to find a secure way to work with logins and sessions since other methods don't seem good or have better ways.

For the website, once you log in if the password and username match should I save a session as a cookie or create some type of token? I would rather it not expire because that would be inconvenient for users but I want it to be secure at the same time.

For the app, when you log in should I also save a session and work with that? Or should that also have a token that auto-renews? I don't want it to keep requiring the user to log in since that would drive people away.

I am using the following software and languages:

App: Xamarin.Forms (C#)
Website: PHP
Database: MySQL

PHP has built in session management that you could use - eg.

session_start();
<?php
    $_SESSION[] = something;
session_destroy(); <- when you want to end that current session
?>

For your form action: <?php echo($_SERVER[PHP_SELF]);> to mitigate xss

if you use this method, each session will assign a user-key on the users machine and when a session is opened elsewhere, it scans for that key - if it matches it accesses that session - if not then it starts a new session.

You can use session_destroy() to kill all session data for that useror session_unset(); to destory a particular session.

If you are using an sql database then you have to ensure that validation is being performed - otherwise you leave your web app open to a number of attacks, ie. XSS, SQLi, etc. which can leak out your users data, for a social media app / website that is very bad for obvious reasons. For a login field for example - something like this would be secure:

<?php
    function clean($string)                    //custom cleaning with regex
    {
        $string = str_replace(' ', '-' $string);
        $string = preg_replace('/[^A-Za-z0-9\-]/', '', $string);
        return preg_replace('/-+/', '-', $string);
    }

    if(isset($_POST('submit')))               // built in sanitising
    {
        $sanitised_name = filter_input(INPUT_POST, 'username', FILTER_SANITISED_ENCODED, FILTER_FLAG_STRIP_HIGH);
    }

    echo $sanitised_name;                    // print out the sanitised name
    echo .clean($_POST['username']).;        // print out using the custom function

   ?>

Above shows two different ways you can achieve very similar results with built in functions. the first block uses regex that you could restrict to whatever character set you wanted your users to use, while the second block uses the built in functions that PHP has - the end just echo's out so you can see the difference for whatever input you use.

EDIT: When storing your users usernames and passwords you should store the plaintext name in your database, but passwords should be salted and hashed, so rather than checking if a username and password matches, check if a username and password hash match what you have in your database - but make sure you set up a secure connection first before a user submits anything - otherwise they are sending information to your site unsecurely - quite easy for someone to MITM and steal credentials.

I actually wrote a paper that specifically deals with securing PHP, SQL, cookies and sessions from attacks like XSS, SQLi, session hijacking etc. if its any use to you i'll leave a link to it below since it goes into more detail: https://github.com/TheresAFewConors/Security/blob/master/Web%20Application%20Security.pdf Just as a disclaimer I don't work in security - i'm a student studying compSec but hope to work in the industry in the next couple of years - if there's anything missing or better than my answer ill happily edit it to improve it since some people on here are extremely knowledgable!

Good luck with with the social media app and website - its good to see that you are wanting to make it secure from the start!


Calculate GPU cracking time Calculating the number of password attempts to crack a password seems fairly simple (John the Ripper - Calculating brute force time to crack password) as an example.  What I can't figure out is how many GPUs it will take to crack a password in a reasonable time.

As an example, how did they determine that this cluster (http://arstechnica.com/security/2012/12/25-gpu-cluster-cracks-every-standard-windows-password-in-6-hours/) creates 350 billion guess per second against NTLM, and "180 billion combinations per second against the widely used MD5 algorithm"  Is it just build and measure, or simply a matter of GPU x does N calcs per second and MD5 requires x calcs per sec to decrypt a password.

I'm looking to find newer numbers than the article from 2012.

It's typically a 'build and measure' process to come up with cracking benchmarks.  Which is not to say that someone couldn't look at a GPU processing capabilities and roughly estimate cracking speeds, but more accurate numbers come from practical implementations.

Once they have a benchmark for a GPU people might certainly estimate how that scales if they add additional GPUs, and this can be fairly accurate to an extent.  At certain points in adding GPUs you have to adapt how you're managing the password cracking across them.  For example, once you exhaust how many GPUs you can put in a single computer chassis you need software and/or hardware to bridge cracking to a second chassis.  This too might run into scalability challenges at another point, depending on how it is being done.  So just keep in mind that going from 2 GPUs to 200 GPUs isn't simply a matter of buying more cards.

The 25 GPU cluster your article mentions was created by Jeremi Gosney and Russel Graves, who continue to build commercial password cracking systems.  Their most recent benchmarks for an un-overclocked 8 GPU system can be found here.  They have other benchmarks with other GPUs available on their Github page too.


Is it better to encrypt to an untrusted key or not to encrypt at all? If a public PGP key can be retrieved, but there is no known path of trust from the sender to the receiver: Is is better to encrypt the message using the key on spec or to not encrypt at all?

Assuming that the key is completely untrustworthy to the point that anyone can decrypt the message, then it can't be any less secure (technically) than unencrypted.

The main risk is psychological, in that you may come to trust the untrusted key.


Why can't Wifi be secured assymetrically? Why couldn't we switch from AES to something asymmetric? Then a private key doesn't need to be shared with the client; rather just share a public key with them.

The concept

I will assume you mean a hybrid cryptosystem, since encrypting everything with asymmetric algorithms would be slow for embedded devices like (cheap) routers. TLS (used in HTTPS) uses the same thing: public key gets sent to the browser, they use that to exchange a secret key (randomly generated for each connection), and from there use AES or ChaCha20 to exchange data (encrypted using the random key).

In WPA2-PSK networks, you can decrypt the traffic from all clients if you know the pre-shared key (the PSK) and were able to capture the handshake that took place at the beginning of a connection. Why do we not use asymmetric encryption, which allows only the recipient to decrypt our message? It would work like this:

Client connects to the WiFi access point (AP)
AP sends public key to client
Client generates a random key, encrypts it with the PSK, encrypts that with the public key, and sends it to the AP
AP decrypts the message with its private key and consequently with the PSK.
Now, they both know the random key, to be used for symmetric encryption.

One cannot setup an AP without knowing the PSK, since they would never be able to decrypt the random key.

The issue: public key verification

There is one issue here: how do you know that you received the correct public key upon connecting? Anyone could send you a public key, also an attacker, and your client would be encrypting the random key with the attacker's public key. The attacker can decrypt your traffic, and relay it to the AP, so you have no idea that you are being intercepted.

Why a CA system can't be used

In HTTPS, this is solved by the CA system, where there are trusted third parties whom can sign your public key. Anyone connecting to the website will check that it is signed by a trusted third party. This works because a CA can easily check whether someone owns a domain: "I will only sign your certificate for example.com, if you put the code 1ZTHrM5OM14fe2ce in example.com/verification". This is not possible for a WiFi network since it requires physical proximity, and there is no concept of having a unique domain name.

Checking the fingerprint

SSH solves this by showing the fingerprint to the client, something along the lines of "192.168.1.1 has the fingerprint SHA256:1OBS2zY..., do you wish to continue?" If you continue, it will store the fingerprint (FP) and the IP address or domain that you were connecting to, so it can just check that it didn't change since last time.

This is also possible with WiFi (after first use, the FP would be stored with the SSID). The trouble is that the full FP needs to be communicated to the client, and the user needs to check each byte. Do you see your grandparents carefully checking whether Wa3rQOGlqo matches the FP published by the owner of the network? If you check only a few bytes in the beginning and/or end, it is trivial to generate a public key whose FP matches the beginning and/or end. It also makes it more difficult to replace your AP, since you'd need to transfer the private key (or re-configure each connected device to trust the new FP).

What is the point of this again?

But why bother? The AP already proved that it knows the PSK. Why do we want to have an additional verification?

Well, the whole point of using asymmetric crypto rather than symmetric crypto, is preventing clients from reading each other's traffic. Anyone with knowledge of the PSK can setup a fake AP and intercept traffic. Therefore it is necessary to employ a scheme which verifies that the correct public key was used.

Conclusion

Because there is no user-friendly way of doing this, I assume. But I don't know of any literature in which this was discussed and rejected. Or any proposed standards that never got to widespread use.

It could definitely be done as described above if people are willing to check fingerprints, but it might be easier to just connect a VPN if you want to protect your traffic.


Can a Bettercap show all the WIFIs around? Can a Bettercap show all the WIFIs around?

Seems like: wifi.show, net.recon on, net.probe on didn't show the WIFI that are ON around. What must be set on or be done?

I did:

sudo bettercap -iface wlan0
wifi.recon on
set wifi.show.sort clients desc
set ticker.commands 'clear; wifi.show'
ticker on
net.probe on
net.recon on

Yes, Bettercap can show you all the wireless Access Points in range.

The reason why you didn't see all of them (or any) depends largely on your hardware and on your exact configuration.

What is Monitor Mode?

When you put your wireless card into monitor mode, you tell it to forward every packet that it receives to the operating system and to any application that wants to receive them. This includes packets of an access point that you did not associate with (aka. "logged in").

This allows you to see everything that is going on around you, on the frequency you listen to.

What is a Channel?

While Wi-Fi operates on radio frequencies, people often don't speak about exact frequencies. Instead, they speak about channels. These channels define a frequency band, which is used to transmit data.

If lots of Access Points are configured to communicate on the same channel, then a lot of noise is generated and the quality of the signal will be worse.

In order to see all the Access Points around you, you need to listen on every channel. Since this isn't possible, you need to "hop" from one channel to the next - just like a radio when looking for stations. This means first you set your card to listen on channel 1, then on channel 2, then on channel 3, etc.

If you want, you can also include the 5GHz channels, which would allow your card to listen to both 2.4GHz and 5GHz traffic.


Is my Java code still vulnerable to SQL injection? We have a Java web application that was vulnerable to blind SQL injection attacks. Our developers fixed the code by using the replaceAll() function to convert single quotes to two single quotes. I am trying to understand whether the following lines of code would still be vulnerable to SQL injection attacks?

String userInput1 = in.getuserInput1();
check = (String)form.get("userInput1");
String userInput2 = (String)form.get("userInput1_express");
userInput2 = (userInput2 == null) ? "=" : userInput2.replaceAll("'", "''");
if (userInput1 != null && !check.trim().equals("")) {
    iQueryObject.addQuery("in.userInput1", userInput1.replaceAll("'", "''"), userInput2, null);
    sbSelect.append("AND WWXX_YYYYMM " + userInput2 + " '" + userInput1.replaceAll("'", "''") + "' ");
}

So far, we have tried to scan the updated application using BurpSuite and sqlmap, both have been unable to identify any SQL injection issues.

The back-end database being used is Oracle.

Yes, your filtering on userinput2 is insufficient, the use of a single quote is not necessary for exploitation with that syntax. I didn't analyse the code any further. "Blacklisting" characters is not a reliable defense against SQL injection. You should alter the code to use parameterized queries instead.


What can be done with Credit or debit card informations asked by websites? Many websites ask for payment by entering information from Credit card such as VISA card/ Mastercard etc.
Now, till date I knew that I should never tell anybody about these numbers. Then why these websites ask for credit card details and if (suppose) any of them have a malicious intent, then what can they do with these numbers?

Basically my question is, how it is being ensured that they will take the specific amount of money/ cost upon my consent; and without my consent they will not take money? Will the bank send me some verification code to my phone?

I never yet used online transactions and I am very confused to understand its steps, do's and don'ts etc. I have searched Google and Quora but I didn't find anything helpful.

I would be thankful if anyone can explain how this specific online transaction mode (by entering credit/debit card number) works and how an without-consent-transaction is prevented, preferably via a flow chart.

Many thanks in advance.

Credit card fraud is a risk managed primarily by two things: chargebacks and anti-fraud monitoring.

A chargeback is when you say "Hey, I didn't buy this."  Your credit card will generally refund you the amount immediately and open a chargeback investigation, which is difficult for the merchant to win unless they have a signed receipt.  The assumption that the cardholder is right is a powerful tool against merchant fraud.

Similarly, the card brands have invested significant resources into the automated detection of fraudulent patterns.  If a merchant you visit does make fraudulent charges, or even just sells/gives your card details to someone else, the card brands can pinpoint the source of the leak by correlating fraudulent card usage against common purchase points.  That merchant then faces consequences including fines and revocation of card processing privileges.

The whole credit card ecosystem is about providing reassurance and convenience to both cardholders and merchants.  In doing so there are trade-offs - such as your card details being re-usable - but the system works well enough to get along.


XSS breaking out of JSON.parse and href attribute I have a pretty complicated case where I try to perform a stored XSS attack when uploading a jpg file with malicious filename.

Whitespace is being filtered but it seems single and double quotes along with < > are not filtered. Moreover slash / and backslash \ seems to be prohibited.

User controlled input is a filename; this filename is first passed to a js script that builds JSON data in the following way (user-controlled filename is represented as INJECT_HERE).

Then the above variable is used to pass the user supplied input to an HTML element. The filename (through foo.myarr.x2.name) is passed to an href attribute (with vue-js and v-bind) and the result html looks like this:

How can I break out of both contexts at the same time to perform a stored XSS? Is it feasible or I try something that can't be done?

You can't do it. Vue uses the DOM to set the href attrib, so it's not hard-coded from the server in a way that could fool the HTML parser. It's simply impossible to set an attrib with the DOM in a way that "breaks out" of the attrib, or starts a new attrib as though you had raw HTML source; all invalid characters will be logically escaped, even if the raw values in the dev tools make it look like the attack should work.

If you did any of the templating on the server (perhaps in an attempt to pre-render) then it's a problem, but as-is, you're safe.

note that data: and javascript: urls could still be an issue, but you've probably already got protection from that setup, given your apparent level of expertise.

EDIT: responding to comment

consider a simple page that uses the DOM to inject content:

   xss

If you look at the developer tools inspect view, you might see something scary like this:

">xss

It appears there's a


Is it secure to encrypt and save third party API secret of users in Database? I want to store third party API secret (like AWS) of my users in database. Leakage of which can lead to a potential loss to my users. It should be kept confidential.

So how can I secure their data on NodeJS platform? I'm thinking to encrypt and store the store the secret key so it will not directly visible to intruders.

Any suggestion on how more security can be maintained?

var crypto = require('crypto');
var assert = require('assert');

var algorithm = 'aes256'; // or any other algorithm supported by OpenSSL
var key = 'password';
var text = 'I love kittens';

var cipher = crypto.createCipher(algorithm, key);
var encrypted = cipher.update(text, 'utf8', 'hex') + cipher.final('hex');

var decipher = crypto.createDecipher(algorithm, key);
var decrypted = decipher.update(encrypted, 'hex', 'utf8') +
decipher.final('utf8');

console.log(encrypted);
console.log(decrypted);

assert.equal(decrypted, text);

It's always best if you can use a system that doesn't require storing reversible secrets. But in some cases, it is required.

Rather than relying on yourself to get crypto construction correct, it's best to rely on a vetted third party library, and this is precisely the niche NaCl was designed to fill. There are many options for using it, in some form or another, in JavaScript:

https://github.com/tonyg/js-nacl
https://github.com/3nsoft/ecma-nacl
https://github.com/graydon/js-nacl
https://github.com/dchest/tweetnacl-js
https://github.com/jedisct1/libsodium.js
https://github.com/wilhelmmatilainen/natrium
https://github.com/paixaop/node-sodium
https://github.com/sodium-friends/sodium-native

The exact API will differ depending on the library you choose, but in general what you're looking for is called secret box.

An alternate approach is to avoid handling storage entirely by outsourcing even that. There are a number of products for storing secrets, including hardware devices. If you're using a public cloud, it probably has a service (here is Amazon's). And Hashicorp's Vault can be run wherever and gives you a lot of control.


What to do if a user loses access to his authenticator code? I have a web service that I set up which allows users to protect their accounts via two factor authentication via an authenticator app like Google Authenticator and Authy.

When enabling it, I mention to write down the authenticator secret in the event you lose access to your device.

Even so, I have users who email me asking to disable two factor auth on their accounts because their phone died, deleted the app, etc...

Are there any other options besides just telling them "sorry, no can do - you lost your account"?

Is there some set of information about a user that I could ask for to give me confidence that they really are the owner of the account (and not just that they have access to the email)?

The only information I collect about the user is their email, password and IP address.

You can use a mix of time delay and backup codes. When the user activates 2FA, show him a couple Backup codes (like Google does) and ask them to save it somewhere, and ask one of the codes on the next screen. This will save you some trouble later.

From time to time, ask the user one of the backup codes when he logs in, even if he submits the 2FA token. If he does not know/don't have the backup codes, generate new ones, send to the user, ask him to save the codes, ask another random one in the next screen. User will be educated that the backup codes are special.

If user loses both the 2FA and the backup codes, create a very long process to retrieve the codes. Show him the necessary steps, how long they will take, and where he is:

User asks for a 2FA reset, send him a link and state that the link will be available from 24h to 48h AFTER he clicks the link
User receives a link telling someone with this IP/OS/browser asked to reset the 2FA, and if was him, he have to wait until next day and click the link.
The next day, user clicks the link and receives another mail with a link and a reset token that must be entered on the site in 24h to 48h later. Add the same message that someone, maybe him, with this IP/OS/browser tried to reset his 2FA.
Next day, user clicks the link, loads a page, enters your site, and enters the token. Tell him he will have to login in 24h to 48h again and 2FA will be disabled.
User logs back in after 4 days, after receiving at least 3 emails telling him someone is trying to reset his 2FA.

I think 4 days is long enough for a hacker to lose interest in the account and a good timeframe to any user to detect and stop any account hijack. If 4 days is not enough, you can increase the time between each email. And any user really interested on recovering his account will follow the instructions.


Hashing and signing partial data in payload I'm hashing and signing part of a payload prior to HTTP Posting from a mobile device to server side. The payload contains of about 7 data elements and only 3 of them are hashed/signed using a private key (RSA) then base 64 encoded and sent to server side. The 3 data elements are sent as a separate param and server is aware of the order of the elements in that param. On server side, after decoding I'm validating the signature (of the 3 data elements) using the public key and if it is successful then I trust all the 7 data elements (aka the entire doc). The question is it safe to trust all the 7 data elements? Or should I hash/sign all the 7 data elements in the doc prior to trusting/using the data.

Thanks

A cryptographic signature can only assert trust on the data it is signing. Unless there's a way to validate the validity of the unsigned fields based on the validity of the signed fields, then no you can't trust the unsigned fields.


Is it safe to store SSN's in Azure Cloud? I'm doing due diligence on a company. They are entirely cloud based and need to collect lots of personal information from users (including SSN). Is this something I should be majorly concerned with? They say they are using encryption, and Azure is a secure platform. I'm unfamiliar with how securely reliable cloud storage is currently, and how complex it is to setup and maintain. If cloud storage is OK for this data with proper precautions, are there any questions I need to ask on this topic?

Given the current state of public cloud, I would argue that in many cases it is in fact more secure than on-premise storage.  Granted I work for Microsoft, but my opinion both pre-dates my employment, and extends to competitors like Amazon and Google as well.  Companies whose business models are built on data center operational expertise and excellence, are simply always going to be better and running and protecting their assets than companies who view IT and data as simply a cost to be tightly controlled.

That said, there are definitely a couple of things that I would take a careful look at.

How are they encrypting the data?  Encryption is easy to get wrong, and with data as structured as SSNs, and with such a small domain, getting it wrong could result in a significant breach of confidentiality.
How are they managing access?  For this you need to look not only at who has access via the application and to the machines, but from an Azure-specific perspective, who has access to the resource groups and the subscription?
Key management.  Azure offers HSM-based key-storage.  For significantly sensitive data, you should ensure they're using an HSM-protected Key Vault.


Do certificates provide any benefit to subresource integrity? What would be the potential attack vectors if a browser were to ignore the certificates when making a network request that is verified via subresource integrity?

As an example, lets say I had the script tag:

<script src="https://example.com/my-script.js" integrity="..." crossorigin="anonymous">

The browser would make the request for my-script, but wouldn't bother checking the certificate, as the validity of the script is verified by the integrity attribute.

The webpage that contains the script tag would still be verified via certificates, but the script itself wouldn't.

Are there any possible attack vectors in this scenario?

Since only strong hash algorithms (i.e. sha-256 and better) are allowed for subsource integrity one can be pretty sure that the payload itself was not compromised. Still, the payload is not encrypted so any sensitive data contained in the payload can be sniffed. This is less likely when including public and static resources but might be the case if the server controls both the file including the script and the script itself.

Apart from that subsource integrity only protects the payload of the response. It does neither protect the response header nor the request against sniffing and manipulation so a man in the middle attacker could at least get the cookies from the request or could even modify existing or inject new cookies in the response. The first one might be used for tracking or depending on the cookie also identity theft or similar. The last one might be used for tracking too. Also, some web applications don't treat the cookies as some opaque value only but use them to store data in it. Changing an existing cookie or adding a new cookie might cause confusion or even cross site scripting, depending on how much the application trusts the cookie value. And the last one is what one tries to avoid when using subsource integrity.


Strategy to migrate Passwords securely from one application to another We are working on a tool that exports data from Source Application "S" to CSV files. These CSV files are manually migrated to box where the Target Application "T" resides. Each line in this CSV is encrypted. The sensitive data being migrated are passwords, password histories and challenge question-answers, etc.

We would be using the AES Encryption encrypt the user data.
The question is should we generate a secret key for each user separately to encrypt/decrypt that specific user's data ?

If yes, how can we manage secret keys for thousands of users and in what form should we store them.

Other Easy alternative is to use one secret key for all the passwords and store this key in a JCEKS keystore.

Which would be a better and more secured approach ?

The question you should ask yourself is: what risk are you trying to mitigate ?

By using a different key for each row, you are attempting to mitigate the fact that, if a key leaks, it will not compromise the other rows. This is balanced by the fact that, the more keys you have, the more difficult it is to manage them securely.

Now, assuming that you're going to do a one-time migration, you're going to have to use ALL these keys at the same time, twice: once during export and once during import. This means that your window of vulnerability will not actually be reduced: there is few chances that one of these keys could be compromised without ALL of them being compromised.

So, in my opinion, I don't think that generating different keys for different rows will grant you any significant improvement in security but I'm pretty sure it will make your job harder.


Exploiting memory corruption issues using a DLL file I was listening to a talk on Return Oriented Exploitation from the Black Hat 2010 conference. The speaker mentioned something about using the DLLs to exploit some of the memory corruption issues.

I know that the DLLs are loaded into the memory only if required by a certain program. But, are they always loaded into some static address range or at any particular memory address? Because, if every time these DLLs are loaded in some random memory address, it'll be really difficult to exploit the memory. (Please correct me if my assumptions are incorrect)

Anyone here with any insights of how this can be done? Is it even possible to exploit the memory vulnerabilities using DLLs?

Depending on how they were compiled, most DLLs use ASLR (http://en.wikipedia.org/wiki/Address_space_layout_randomization). Some do not, so this makes them easy to exploit. If there is some sort of information leak (printing out a function pointer or something), then the randomization doesn't matter because the attacker knows the randomized address.


Authorization based on OASIS ABAC/RBAC/XACML approach Is anybody aware of any open source .NET authorization solution based on OASIS ABAC/RBAC/XACML approach?

I have found some visible amount of Java based solutions but it seems .NET is completely out of it (lack of interest, not in trend?).

What does .NET community use then to implement Attribute or Role based authorization?

Actually, there are (have been) several commercial implementations on .NET:

Bitkoo (acquired by Quest then Dell, now defunct)
ViewDS (Australian-based, integrated with their virtual directory)
Axiomatics (both Java and .NET) (disclaimer - I work there)

In the open-source space, there are definitely more Java engines than .NET engines but that is likely due to the nature of the languages. Java is more prevalent than C#. There is even a PHP project for XACML.

 (Source)

That said, the implementation language shouldn't really matter to you. XACML offers authorization as a service that sits within your infrastructure and can be easily consumed from multiple languages. XACML defines a REST/JSON interface which you can easily use.


Risk of keeping OAuth2 client_secret in application As an exercise, I'm developing a desktop application with which users need to log in to a web service. A logical use-case for OAuth2 one would say, but I'm beginning to doubt its usefulness. I am looking for two-legged authentication, which leaves the client credentials, implicit and resource owner password flows available.

Because I would like users to be able to directly log in inside the application (not through a browser and redirect URI), the implicit flow falls away as an option. The other two flows require for the client_id and client_secret to be sent along, and I've read plenty of times it is unsafe to store the client_secret inside your desktop application.

My question is this: how unsafe is this really? How easy is it for adversaries to decompile (desktop) applications and figure out the client_secret? I could consider accepting the risk, so that I can use OAuth2's client credentials flow, because rolling my own authentication scheme would probably be even less secure.

P.S. Someone mentioned using implicit flow and temporarily starting a webserver at localhost as the redirect URI to circumvent a browser, but that seems excessive if not insecure. Any thoughts?

Look into the process of OAuth for client-side applications.

Your OAuth flow should look something like this:

User logs in
Your API returns an access token for that user
Your desktop application stores the user token
Future requests send the token, and the API uses it to authenticate the user

You cannot realistically protect a global secret key in your application, nor do you really have to.


Backing up PCI data outside of the cardholder data environment Assume a cardholder data environment (CHDE) is segregated appropriately, data in the environment is encrypted at rest and in transmission. We have a backup service that sits outside the CHDE. If we create an ACL to allow the backup service to run backups in the CHDE, this would potentially allow an admin to bypass multi factor authentication into the environment, by using the same ACL from the backup server/service. Am i right in thinking the only way to do this is to create a service inside the CHDE to run the backups, then push those files out of the CHDE to a remote storage???

When you create an ACL and allow your backup environment to access your CDE, it means your backup servers and the flow on the way to those servers are also in PCI scope. You can either create another big workload to yourself for auditing this new scope and creating MFA for this flow or you go with the option you think.
I would go with a service inside the scope and make sure data is stored in a safe and different place from the other backups. (check PCI v3-2-1 requirement 9.5.1)
Link: https://www.pcisecuritystandards.org/documents/PCI_DSS_v3-2-1.pdf


Is authentication using personal pictures more secure than passwords? Statement 1
There is a start up called PixelPin. On the web site it reads:

The PixelPin solution is simple and quick to use, yet very secure.
PixelPin eliminates the traditional alphanumeric password by using a
picture based approach. The user chooses an image that’s personal to
them (e.g. a photograph of their family or a memorable holiday photo).
They then choose 4 points (Passpoints) in sequence on the image. The
PixelPin process eliminates the risk of phishing, dictionary attacks
and brute force hacking. There’s also a growing body of academic
research suggesting that people remember Passpoints on a personal
image more easily given the emotional connection evoked during the
process.

Statement 2
However, Cleopatra, a certificate manager for OpenPGP and X.509 (S/MIME) and common crypto dialogs, says that

Photos give a false sense of security.

Statement 1 seems to contradict Statement 2.
Question: what is this noise about picture-based authentication. Is it secure to use or not?

The two statements speak of completely different things. They don't contradict each other. That does not make them both true, though.

PixelPin: this product apparently replaces the password by the selection of four positions on a picture. This means that you choose a picture, and your "password" is the sequence of coordinates for four points you choose on the picture.

Since users cannot be relied upon to always click on the exact same pixel, especially since they claim support for touch screens, one must assume that the pixel selection is kind of fuzzy. If we suppose a full-screen picture on a smartphone, we can hope for, say, 200 possible selection points in the picture (it is as if the click from the user fell on a 20x10 grid). The implementation must do something smart to avoid threshold effects (when the user chooses a selection point which is close to the boundary between two grid elements).

Four selection points then means 2004 possible "passwords", i.e. an entropy of a bit more than 30 bits. While this is not bad, as far as passwords go, this is not exactly the most robust password ever. An important point to make is that human users are unlikely to choose "really random" points on the picture. As the example on the page shows, human users will click on the cat's nose, not on a random place in the back wall, if only to be able to click again on it at the next login attempt. I seriously doubt that in real conditions, human users would achieve enough randomness in their selection to defeat brute force attacks.

The PixelPin company claims that using a user-chosen picture makes it easier for users to remember their points; that I am ready to believe. They talk about the Picture Superiority Effect, a pompous name for the fact that humans are apes and apes are very visual animal -- primates have had good vision for about 50 millions of years, while writing is human-only and no older than about 6000 years. It is no surprise that human memory groks pictures efficiently. Our ancestors were highly trained to remember how a lion looks like (let's say that the career of those who could not remember that was, on average, shorter).

Overall, I find the claims of PixelPin a bit bold, quite possibly outrageous. The idea is interesting, though.

The picture in certificates is something else. A certificate is about binding an identity with a public key. A picture could be thought as part of the identity.

The people at Kleopatra states that they don't want to support pictures for several reasons, among which the idea that photos give a "false sense of security". What they mean is that a photo is a reasonable part of the identity of a person only insofar as the issuing CA checked that the photo was really that of the target person. This seems dubious, unless the issuing CA took the photo itself. Right now, with certificates as they are used today, photos in certificate are merely advertising; they are pictures of what the certificate holder would like to look like, and not pictures of the key owner as he really is.

Briefly said, pictures in certificates tend to give users warm fuzzy feelings about some assumed enhanced security (by analogy with ID tags and passports, mostly), but these feelings are largely unsubstantiated. Kleopatra developers feel it their duty to protect users against such things, hence the absence of support. (Or possibly they were just lazy and did not want to implement the support for pictures.)

This is completely different from what pictures are used in PixelPin. PixelPin is about pictures as support for human memory. Kleopatra is talking about pictures as part of the physical identity.


Authentication system for a web service I am building a web service which i will be launching in near future. Service is more or less like online classifieds.

Now, i need to build a mechanism to collect user's information, enough to trace him in case of any fraud with other users. I can ask for nation ID card and things like that. But problem is that how will i verify them and the person providing the information.
So, i need suggestions for such system which could be used t authenticate users, so other users can trust them. And contact them freely knowing in case of any mishap authorities can get its information from our service.
For solution we must consider that our service will be free so if this process is costly, than their might be a mechanism to get that cost paid by users.
Any suggestions will be appreciated.

It depends how much verification you want. You can verify that the ID number entered matches the details supplied (assuming that whatever nation the ID card belongs to provides some sort of API to do this - lots of countries don't even have standard ID cards though), but all that proves is that the person entering the data knows both the card number and the details that are associated with it in the national store. If I stole your wallet, I can probably make a pretty good guess at that link - bound to be something (driver's licence, passport, etc.) with your full name and enough of your address to be able to get the rest from online services in there.

You can't verify that a specific person entered the details, nor that (with some exclusions, perhaps vehicles, buildings, and land) they own the thing they are offering for sale.

If your marketplace is for relatively low value items, verifying email addresses might be enough. For more expensive items, you might want to look at verifying bank account details - look at sites like Paypal for how this works. For high value items (houses, for example), you'd probably want some manual verification steps in the process - having a copy of identification documents made by a solicitor or similar. Depending on the country, there might be legal requirements for specific types of goods - cars might need to be recorded in specific ways and registration documents provided to a central database, say.

In general though, for a purely online process, all you can state is that someone who knew some details about a person entered them.


Scanning documents and ISO-27001 We are planning to submit a project to our managers about scanning all our office papers and deal with PDF instead of physical-format documents.

For doing that, we are loooking for some support, if there is any, for claiming that scanning documents is a good practice that is aligned to ISO/IEC-27001 policies.

We know that the main purpose of an ISMS, based on ISO/IEC 27001 requirements, is to reduce the risk of losing information or unauthorized access to it.

However, do you think that we could align the activity of scanning documents with ISO/IEC 27001 recommendations?

We were thinking that getting PDF files reduce the risk of losing physical-format documents, because file backup procedures are more secure than  protecting papers.

In theory it is entirely possible that digitising paper documents could improve their overall security, but it depends on the specifics and how well protected/controlled the current environment is, and whether that will be improved once the new project is rolled out.

If you're looking to make this case, you could look at your organisations current risk register to see if there is anything there relating to storage and management of physical documents and then assess whether your project will address these risks.  If it will then you could easily claim that the project is in-line with the goals of ISO27001.

Of course that could be slightly disingenuous as it doesn't take account of new risks being introduced by the project, but then hopefully you'll already have those under control in the project risk register.


Looking for STIG/SCAP Scanner Problem:  I wish to build a VM that I can take onsite to clients to perform "SCAP" like scanning of their domain controllers.  I don't need vulnerability scans in terms of like missing patches or exploits.  I am more interested in things like Group Policy Settings and what the DoD (or other big named standards entity) says is "best practices".  I don't think STIGS are the end all, be all of compliance or security but just one more like thing I can provide my clients while I am onsite.  I'm always looking at what more I can provide them and this is one thing I really wish I can could.

Background:  I am former Active Duty Air Force and now a Reservist.  My civilian job is performing identity risk analysis for our clients.  I technically have access to the DoD SCAP scanner and my company's Nessus license.  However, the Nessus platform is used by our PenTest team and they have a bigger need for it than I do.  My job doesn't require a VulScanner so I can justify purchasing another liscense.  However, also don't want to have to wait on another office is they are utilizing the platform or if the client doesn't allow remote scans from the internet to the internal network.  I don't feel right using the SCAP scanner as it is a DoD product and they have made sure the commercial market doesn't have access to it.  Circumventing their process just because I still have a military CAC seems wrong when I am performing consulting for clients.

What I have researched:  I have looked it using OpenSCAP and OpenVAS.  OpenSCAP is a no go as they told me directly they do not have Windows scanning capabilities.  Yes they can import the SCAP data, but in they can not perform scans against Windows machines.  Still researching OpenVAS to see if I can tweak the scans to only do STIG/SCAP content instead of looking at full blown vulnerability scans.  Finally, also looking into Microsoft Best Practice Analyzer as maybe a compromise if nothing else exists (which means I'm pigeon holed into what MS thinks is best).

You could use JovalCM.com but I honestly don't see why OpenSCAP or ovaldi would also not work. OpenVAS supports integration of ovaldi in its checks if you set it up in the advanced configuration.

SCAP requires credentials and the output from OpenVAS is also suspect (e.g., lots of false positives, false negatives, and other errors) when performed without credentials and proper configuration. CIS-CAT is one good, commercial alternative to these tools, but there are even better ones. My favorite is Symantec Control Compliance Suite.

My suggestion is to implement as much of a security baseline as you can from:

https://adsecurity.org/?p=3299 (Secure Windows Workstations)
https://adsecurity.org/?p=3377 (Securing Domain Controllers)


How should a backdoor be delivered? I am wondering about the ways a backdoor could be delivered to someone and the advantages and disadvantages of the various ways.

As a backdoor, I mean a script or payload that may be able to get a reverse tcp/http connection to a server in a way to obtain informations from the victim. This script could be sent as an embedded file, through any kind of direct access of the computer's victim, or even click-jacking.

What I would like to know is: Is it better to deliver only a piece of the whole backdoor(the one with some basic functions like: the connection one, download of files, upload, etc). Then, after obtaining access to the computer send other files (.exe) with functions like keylogger, packet filter, password dump, etc? Or would it be better to send only one file (.exe) containing all the functions, the whole backdoor?

What are the advantages and disadvantages of both methods, when should I use each one?

There are many different types of backdoors which an attacker could setup on a system. These include

Adding an account with administrative privileges.
Adding a daemon to a system which listens for connections, possibly on a high port, and provides remote shell access.
It could be software running on the system which calls out to a remote site for commands it needs to run.
Modification to existing system configurations or applications such that commands can be remotely executed.
Modification or addition of code to things, possibly a website, which would then allow remote code to be executed. PHP shells would be an example of this.
Modifications to documents that when parsed or opened allow for code execution or remote requests.
Etc... Possibly hundreds of other examples.

As you can tell not all of these would need to have a script involved and also most of these could be set up via the execution of a script or program. Your question is a bit broad as currently written (at the time I'm reading it) but hopefully this helps answer it.


What vulnerabilities would this type of "password manager" have? When I was searching for a password manager to use I stumbled upon the concept of Master Password which instead of encrypting and saving your passwords, generates them by using your master password and the name of the service/website you use it for. This way your passwords don't have to be stored anywhere since they are generated every time you enter your master password in the app. I liked this concept but I wanted to try making my own app for this.
So what I thought of is basically:

get master password and service url from the user
add the strings together
create a hash of this string using SHA-512
use this hash as the seed for a PRNG that generates the password

Now my question: If you use a good master password, would there be any security risks concerning this concept?

This password manager have the downsides of making formulas for creating passwords, and lacks the flexibility of a proper password manager.

The most obvious issue is that the passwords are deterministic. It means that if you come across a website that forces you to use exact one digit on the password, you cannot use your password manager to generate it, as you don't control any aspect of the generation process.

The second issue is that you cannot easily rotate passwords. If any of the passwords leaks or expires, you will have to code workarounds for each one.

The last one is that the master password cannot be changed, or it invalidates every single password you have. You have to change every password on every site, and that is bothersome, to say the least.

What could you do? For an experiment, not for real: create passwords using random generator (may it be chars, words, or a mix), encrypt them using a symmetric key, and use the master password to encrypt the symmetric key.

This way you can change any password at will, and encrypt just the changed password. You can change the master password by decrypting the current symmetric key, generating a new master password, encrypting the symmetric key with it, and saving it back.

But unless you are a very talented programmer with a broad knowledge on cryptography and secure programming, don't write a password manager that will be used by anyone but yourself.


Something similar to owasp for wifi/networks/desktop/servers/...? Is there a site or project similar to owasp.org for other systems or devices which a commonly subject to penetration testing?

Which ones?

There are many sites dedicated to these topics. There's the National Vulnerability Database, which has both CVEs, known vulnerabilities, and CCEs, configuration issues. https://nvd.nist.gov/

There's the NIAP program which covers a wide variety of products. https://www.niap-ccevs.org/Product/

You can look at the Center for Internet Security benchmarks, which also covers a wide variety: https://benchmarks.cisecurity.org/


Does the use of JavaScript make ProtonMail insecure? I like the look of ProtonMail. However, what has stopped me from signing up is that JavaScript seems to be used at various points in the site, and for someone to read your email they must click on a link to what I believe is a JavaScript page?

For people like me that use Tor Browser Bundle with NoScript: even if the site is usable, what about the end users that want to view the contents of your message while on Tor?

I am worried about something like what happened to Freedon Hosting. But, even without an exploit I've seen rather simple attacks using JavaScript to unmask someone.

This seems like a pretty stupid thing, but I am far from an expert. Am I wrong here, overreacting, or is this an actual huge vulnerability that for example the FBI (or whatever Switzerland has) could use to get an IP address?

EDIT: I found this article which is my worry.

Note: this question might have been better on the Tor community despite being on-topic here.

Thomas Roth demonstrated that Protonmail was vulnerable to a Cross-site scripting (XSS) attack.

The video (Vimeo) he made shows that at least the mail body was vulnerable to Javascript injection. As soon as the receiver read the mail, the code is executed. Unfortunately, this code can be malicious and can, among other things, deanonymize the user. The FBI showed that it was possible when they seized Freedom Hosting. (Although they exploited a 0-day in Firefox.)

Using the Tor browser with Javascript enabled is risky. Disabling it will reduce the attack surface. The Tor developers are aware of this issue and address it in their FAQ:

  Why is NoScript configured to allow JavaScript by default in Tor Browser? Isn't that unsafe?

  We configure NoScript to allow JavaScript by default in Tor Browser
  because many websites will not work with JavaScript disabled. Most
  users would give up on Tor entirely if a website they want to use
  requires JavaScript, because they would not know how to allow a
  website to use JavaScript (or that enabling JavaScript might make a
  website work).

The Tor browser gives you the opportunity to disable JavaScript (with the NoScript plugin). However, as you may have noticed, Protonmail relies importantly on JavaScript, and disabling it would prevent you from using their service:

  Why do you need JavaScript, Session Storage, and Cookies?

  ProtonMail does encryption and decryption of messages in your web
  browser.

  This ensures that we do not have the ability to independently decrypt
  your messages and thus ensures the security and privacy of your data.
  In order to do encryption and decryption in your web browser, we need
  to use JavaScript for the encryption/decryption and SessionStorage for
  saving your private key(s) locally. ProtonMail also requires cookies
  to be enabled so that we can store your current session information
  and log you into your account.

(Last emphasis is mine.)

Therefore you have to make a choice. Either you decide to trust Protonmail to be secure (even though vulnerabilities have been found); or you walk away and find another solution.


HTTP BA from a different Server There is a weird situation that I am stuck with regarding HTTP Basic Authentication.

Below is a hypothetical situation:

Lets say there is a certain domain, say https://myfacebook.com
and there is a certain URL as : https://myfacebook.com/view_my_profile?imgURL=anyImageURL that myfacebook.com has designed so there users can share their profile pictures with each other without even logging into the site.

anyImageURL can be any URL assuming that myfacebook.com wants to give this flexibility to its users to load any image here from any location.

Now also to reiterate, lets assume that the URL can be accessed by anyone publicly without any authentication.

Now lets assume an attack scenario:

An attacker takes the URL https://myfacebook.com/view_my_profile?imgURL=anyImageURL from google cache (that he finds using some Google dorks for example) and replaces the anyImageURL with a server that he has hosted lets say http://attacker.com. And lets say that the attacker had configured http://atacker.com to serve 401 page (HTTP Basic Auth page)

And sends the following URL to the victim to make the victim make a final request as:
https://myfacebook.com/view_my_profile?imgURL=http://attacker.com

Now when an UNSUSPECTING victim clicks on the URL
https://myfacebook.com/view_my_profile?imgURL=http://attacker.com the victim gets presented with HTTP BA pop up and he may be lured into entering his myfacebook.com credentials.

Now my question is:

  If at all the victim enters his credentials and submits them WHERE WILL THESE CREDENTIALS GO ? To myfacebook.com server because the page itself is being hosted on myfacebook.com or to attacker.com because the HTTP BA came from attacker.com ?

The credentials go to the server requesting them, in this case, the server serving the image. (attacker.com in your example.)

This is called a 401 phishing attack, and while rare, I have seen it in the wild so it is something that you need to consider if you're going to allow images to be loaded from arbitrary domains.


Is it safe to use a unix pipe to redirect sensitive output data as input to another program? I want to make a Node.js development server use HTTPS by giving it access to the contents of a TLS certificate and private key file.

On the one hand, I don't like the idea of making the TLS private key file readable by anyone other than root. On the other hand, I like the idea of running the Node server as root even less.

So it occurs to me that I can avoid resorting to those methods by starting my development server manually with the following shell command:

sudo cat /path/to/private/key/file | /path/to/node/server

(In my case the server program can be configured to read STDIN and parse the key contents as necessary.)

My assumptions here are that the pipe (the | in the command above) is anonymous (in contrast to named pipes), and that unprivileged 3rd programs are unable to access the file descriptors corresponding to them (at least on Linux?). Is that correct?

Are there any other security aspects I need to be aware of? Is this a good solution, or are there better alternatives?

The | is anonymous.  The pipe will usually not be accessible to anyone who isn't root or the owner of one of the processes.  As soon as you read the standard input and close it, the cat process will exit, and the pipe will no longer exist to even be exploitable by root or the owner of the remaining process.

That said, it's usually less hassle to code your program to start as root but drop privileges before it gets to the point of actually paying attention to anything coming in from external.  This is the mechanism that's used in email and web servers to let them listen to a privileged port, but not be seen as a root-level externally accessible security hole waiting to happen, for example.


Is it possible to use parallelism when computing a key derivation function for a single password/key? Suppose I have an AES-256 encrypted file, and I want to derive the key using PBKDF2 and a given salt with a large number of rounds (say 1 million), but I'm limited by user tolerance for UI lag when entering their password. Is it possible to compute a key that is similarly resistant to cracking by computing 100 keys in parallel from the same password and 100 different salts, for 10000 rounds, and then hashing them together with a hash function such as SHA-256?

The standard way is basically this:

key = pbkdf2(pseudo_random_function, password, salt, 1000000, 256);

A parallelizable way could be like this:

for(i = 0; i < 100; i++)  // parallelize this on the GPU/FPGA etc
{
  partial_keys[i] = pbkdf2(pseudo_random_function, password, salts[i], 10000, 256);
}
key = sha256(concatenate(partial_keys[0] ... partial_keys[99]));

Assuming the derivation method was known to a cracker, would this yield a key that was similarly hard to crack as the standard way, and would it be as secure? If not, roughly how secure would it be (if it is secure at all) in terms of equivalent number of rounds using the normal approach?

Perhaps it's not necessary to store 100 salts, you could just store 1 salt and then generate 100 different salts from it using key-stretching techniques/block ciphers etc. If this was used in an application, you could assume or enforce a minimum GPU capability before allowing the user to install it.

The point of this would be to reduce the latency (time taken to derive a single key for the user), without increasing the throughput (number of keys that can be derived in a given time period with a given amount of computing power by a cracker).

Most hash functions take measures to make them hard to implement on GPU's, but it is indeed also possible to take advantage of parallel execution and use that on the defender's side when verifying passwords. One algorithm that was designed to be easily parallelizable is parallel by Steve Thomas. Parallel was a finalist in the PHC and thus has gotten some review, but I could not find much information on it.

So the idea behind your algorithm is sound. The implementation looks good to me, but you may want to ask a real cryptographer before you take it in production.


Is it a good idea to deprecate support for some insecure clients on a website? I have a scenario where a secure website with an A ssllabs overall rating is getting some warnings due to a lack of support for non-SNI browsers.

Android 2.3.7 Incorrect certificate because this client doesn't support SNI
IE 6 / XP Server closed connection
IE 8 / XP Incorrect certificate because this client doesn't support SNI
Java 6u45 Client does not support DH parameters > 1024 bits

I got the idea (maybe not the best one) of allowing those browsers to reach the website by sending the requests to a secondary insecure (non-https) backend using the http user agent information.

I understand that allowing those clients to reach the website would be a security breach, but at least They'll be able to see the website.

So, my question is about a security conception, what is worse/better? Allowing those clients to reach the website even if it means a security issue, or to deprecate support for those browsers?

In your particular case, dropping the support seems like a good idea.
Every new service you provide, adds a potential attack vector. Apart from that you increase the maintenance cost of your product. Adding a completely new support mechanism for less than 0.01% users doesn't seem like a good idea to me unless they are significantly important users (say have a 10% share in your income or something).

However, you can have a safe website which uses HTTP (Stack exchange doesn't use HTTPS). In a general scenario, I would say the decision is more related to economics and maintenance issues rather than technical issues.

How badly do you want a A rating?
Do those customers generate enough revenue to balance the maintenance cost of non-HTTPS servers?


Why doesn't NordVPN require sudo? I've downloaded and installed NordVPN on Ubuntu and am a bit incredulous at its operation.
After I downloaded its .deb file and installed it, apparently it can be activated with the command nordvpn connect, and I'm expected to believe that this command encrypts and reroutes all packets from my machine to go to their servers first.
This seems like a pretty big operation that should require communication with the operating system. If I had multiple users on my system, they are all suddenly having their applications redirect to NordVPN's servers. Why doesn't it require sudo?
I should note that other VPNs with command line interfaces seem to work this way as well (ExpressVPN).

NordVPN uses /var/run/nordvpnd.sock to allow the nordvpn client tool to communicate with the nordvpnd daemon (which is running as root).


What should be done if 2FA was turned off in an unexpected manner? Today when I logged in Facebook, no 2FA was shown.

I have been using SMS message as the second authentication factor. When I looked at the security settings, 2FA seemed to be disabled. I immediately set it up again, and performed the security check (change password, check phone number, posts, comments) offered by the "Not me" log-in option.

Since I usually use Facebook on semi-public computers, the account might be hacked. Are there any other things that I should do to protect the account?

I assume that there should be some SMS confirmation before succeeding in turning off 2FA, but I received none. Should I worry my phone's security? Also, although I didn't reuse my Facebook account password on other sites, are there other credentials I have to change?

The authentication token/cookie was probably saved and you were not prompted to login in with 2FA/MFA. Normally changing 2FA/MFA settings requires you to input a new OTP again so unless you're second factor was compromised you're most likely safe in terms of access to the account - data can have been stolen/compromised. Also consider using an option that is not SMS for 2FA/MFA like an authenticator app or yubikey (U2F).

More information
https://www.yubico.com/products/yubikey-hardware/
https://pages.nist.gov/800-63-3/sp800-63b.html
https://www.facebook.com/help/148233965247823/


Raw hard disk data extraction possible? Suppose that the administrator's account is hacked.

Then, can a hacker extract hard disk raw data (by raw data, I mean every raw data, not just files that can be read by a file system.)?

If an attacker gained administrator rights, he has direct access to hard drive in your computer and, as a result, he can recover any data from it. Just like "real" administrator. So answer to your question is YES.


Wireshark tcp filter: tcp[((tcp[12:1] & 0xf0) >> 2):4] While reading this doc https://wiki.wireshark.org/CaptureFilters I found this line:

tcp[((tcp[12:1] & 0xf0) >> 2):4]

which figures out the TCP Header Length, but I can't find out how it really works (in detail).

Can somebody explain it?

I presume you pulled this from the "capture HTTP GET requests" filter example.

First, some notation:

var[n] means the nth byte of var.
var[n,c] means c bytes of var starting at offset n, e.g. var[3:4] would return bytes 3,4,5,6 of var.
& is the bitwise AND operation.
>> means bitwise shift right.

So, what do we have?

tcp[((tcp[12:1] & 0xf0) >> 2):4]

Let's deconstruct this into its individual parts:

tcp[12:1] takes 1 byte of the TCP segment (i.e. the packet including header) at offset 12. We can see from the structure that offset 12 (0xC) is the Data Offset field. Its definition is as follows:

  Data offset (4 bits) specifies the size of the TCP header in 32-bit words. The minimum size header is 5 words and the maximum is 15 words thus giving the minimum size of 20 bytes and maximum of 60 bytes, allowing for up to 40 bytes of options in the header. This field gets its name from the fact that it is also the offset from the start of the TCP segment to the actual data.

Ok, cool. This field is only 4 bits, though, and tcp[12:1] takes a whole byte (8 bits). We only want the first four.

tcp[12:1] & 0xf0 takes that Data Offset byte and applies a bitwise AND operation, using the constant 0xF0. This is often known as a masking operation, since any bits in the constant set to 0 will also be set to zero in the output. It's easier to think about this in binary. 0xF0 is just 11110000, and since x & 0 for any bit x is always 0, and x & 1 for any bit x is always x, it follows that the zero bits in 0xF0 will "switch off" or mask the given bits, but leave the rest alone. In this case, if we imagine that tcp[12:1] is 10110101, the result would be 10110000 because the last four bits are masked to zero. The idea here is that, since the Data Offset field is only 4 bits long, but we have 8 bits, we mask out the irrelevant bits so we only have the first 4.

The problem here is that, numerically speaking, our 4 bits are in the "top" side of the byte. This means that instead of just having 1101 (our Data Offset bits), we have 11010000. If we just wanted to get the "raw" value of the Data Offset field, we'd right shift by four places. 10110000 >> 4 = 1101, i.e. we throw away the "bottom" 4 bits and shift the top four bits right. However, in this case you'll notice the filter only shifts across by 2 places, not 4.

This is where we want to refer back to the definition of the Data Offset field: it specifies the size of the header in 32-bit words, not bytes. So, if we want to know the length of the header in bytes, we need to multiply it by 4. As it turns out, a bitwise left-shift of 1 is the same as multiplying a number by 2, and a bitwise left-shift of 2 is the same as multiplying a number by 4.

Now, combine this with what we've already seen: >> 4 would make sense in the filter if you wanted to get that raw value of Data Offset, but then we want to multiply it by 4, which is equivilent to left shifting (<< 2), which cancels out part of that right shift, resulting in >> 2.

So, (tcp[12:1] & 0xf0) >> 2 extracts the Data Offset field and multiplies it by 4 to get us the size of the TCP header in bytes.

But wait, there's more!. In the filter you provided, we still need to do one more operation:

tcp[((tcp[12:1] & 0xf0) >> 2):4]

This is easier looked at if we used an intermediate variable:

$offset = ((tcp[12:1] & 0xf0) >> 2)
tcp[$offset:4]

What this does is get the first 4 bytes after the TCP header, i.e. the first 4 data bytes of the payload. In the filter you pulled this from, they were looking for HTTP GET requests using this filter:

port 80 and tcp[((tcp[12:1] & 0xf0) >> 2):4] = 0x47455420

The 0x47455420 constant is actually a numeric encoding of the ASCII bytes for GET (that last character is a space), where the ASCII values of those characters are 0x47, 0x45, 0x54, 0x20.

So, how does this work in full? It extracts the 4-bit Data Offset field from the TCP header, multiplies it by 4 to compute the size of the header in bytes (which is also the offset to the data), then extracts 4 bytes at this offset to get the first 4 bytes of the data, which it then compares to "GET " to check it's a HTTP GET.


Is DRM considered Confidentiality, Integrity, Availability, or some combination of the three? I was discussing software trial time limit enforcement with a colleague and the idea of CIA came up. Do stricter enforcement techniques increase confidentiality at the expense of availability? (for example when an application MUST phone home to authenticate and therefore cannot be used offline) Or is this integrity? Maybe some combination?

How would you frame software trial time limit enforcement in terms of CIA? What about DRM in general?

No. DRM doesn't really guarantee anything.

Confidentiality is the guarantee that an unauthorized user cannot access the protected information. DRM doesn't guarantee this because decryption keys are necessarily distributed to the very person you're trying to prevent access to.

Integrity is the guarantee that the data hasn't been tampered with. DRM doesn't give this either, for the same reason as above. While DRM usually employes encryption, it invalidates any of the guarantees that encryption would otherwise provide by disclosing the secret key to the attacker.

Availability is the guarantee that an attacker cannot prevent access to critical data. In the case of DRM, if protected data is available it is despite the DRM, not because of it. There have been several well-known cases of attackers being able to deny access to protected content by attacking the key distribution points, an attack that wouldn't have been possible without DRM.


Choosing token over session or vice versa? I wanted to build a secure user interaction to the server, but I stumbled upon using either token or session. Here are couple of options that I thought about:

I learned JWT, built a token, and sent it back and forth between server and client in my local server. Seems like a good thing to do, since using HTTPS, only two parties will be able to communicate in between, therefore quite secure.
However, when I looked into the websites like Facebook, Twitter, Instagram, they don't have token, but have session with bunch of variables. I assume they are for authentication.

Which option is a right way to opt? I opt to choose token, as it is secure, I say, why burden server with the load client can handle when you can offload if token is used.

However, I have a feeling that tokens are basically not used in website, but only in APIs.

A token and a session is basically the same thing on a different view. A cookie would be a different thing.

As the HTTP protocol is stateless, the server must have a way to maintain the state of the connection. A session (generally) is a file stored on the server, with all the state variables of the client on it. The token is the value send back from the client, so the server knows which file to read. A session and its token are more secure than a cookie because the client cannot change arbitrary fields, and generates less traffic.

A cookie is another approach: it's a file stored on the client with all the session data. They store all data of the connection. I don't like cookies because of the overhead of making sure that the client haven't changed any value.


Where to put a code signing server with EV code signing certificate and plugged-in HSM Microsoft recently started enforcing apps to be signed by EV code-signing certificates instead of just regular certificates. These usually come on an external device such as USB smart card or a HSM, where the private key is stored and can't be exported.

SW company that wants to sign an app with EV certificate probably has automated build/deployment process. The build infrastructure is either (1) in cloud, or (2) locally in a server room/building, or worse (3) in a rack in their office. Having the "sign" server separate is probably the best idea, the signing device is connected to it and release executables are only signed on this server.

My question is: Where to put this sign server in all three scenarios?

If we have our build infrastructure in the cloud, should we tunnel to a local VPN where the sign server is located? Where should the sign server be in this case?

Or even if we have our private build infrastructure locally, should the "sign" server just be a random server in server room/building along with other 10s or 100s of servers? Will I just plug the sign device to USB of one seemingly "random" server in the server room? Maybe a better approach would be to have a special room with cameras and restricted access. What if we don' have a private server room though? What if we rent a rack? Should the key just "lay around" in the rack?

How to scale this? What if we have 10 different apps with different keys? Do we go to this server every year and change it physically after expiration?

This thread is partially related What Are Good Code Signing Environment Guidelines?, but it was closed as too broad.

Since I think all 3 of the CIA model would apply here, you would want to physically store it in a location where you can enforce physical access controls to restrict access to only those that need access to it. You would also want to install a FIM (File Inegrity Monitoring) solution of some type to ensure the integrity of the file system doesn't change from unauthorized changes. I would recommend locking it down based on one of the CIS benchmarks depending upon the operating system along with a host-based firewall and probably have a network firewall in front of it to restrict network access to it as well.


Can you use ssh for secure inter app communication on the same device? I use ssh to get an encrypted connection between servers and local machines all the time. It's fast, it's secure, and there's a way to do it in nearly every system programming language that I've used so far.

My question to you is, can this simple interface be used for secure inter app communication on the same device?

I don't see any flaws with it working with android, Linux, or OS X. I would suppose operating systems like iOS have time constraints for ports being opened but even in that case all you would need to have is background app refresh enabled in order to open the receiving ports from the app being called.

Is there something wrong with my logic in this case? Everything that I've experienced with using ssh so far tells me it would work but, I would love to hear your opinions on this because I really like ssh and wouldn't mind making a little API that provides safe inter app communication.

You say "SSH is fast". It's not. It's fast enough for its intended purpose (remote shell access and occasional file transfer/sshfs) but it's definitely not fast enough for IPC, let alone efficient.

On a local machine there's never any need for encryption between processes. If an attacker can read what you're sending to localhost, he can most definitely read the entire memory and get the key to whatever crypto you're using.

You also need to consider battery life, adding (unnecessary) crypto will induce more CPU load and thus more power usage.


Can a website steal passwords saved in my browser? Today I was on Steam and someone sent me a link and asked me to vote for him in some online gaming league. I clicked on it and the browser told me that this could be an unsafe link so I didn't proceed further. Then I opened in another browser to see if it was a legit site.
I see that this was a domain registered today and on it there are some game related content but it looks very suspicious. What I am curios about is if I am at risk? Can they steal browser content such as bookmarks or saved passwords and cookies by just navigating to a website?

If it was that easy, we wouldn't be using browsers. However, if your browser has a vulnerability, then things like this may happen.
Keep browsers up-to-date and run script blockers, like no-script, to prevent this type of attack.