Does TLS_FALLBACK_SCSV provide blanket protection against downgrade attacks? The TLS_FALLBACK_SCSV flag was touted as a way to prevent POODLE, which abused the potential to downgrade to SSLv3 from TLS. Does the implementation of this flag prevent similar downgrade attacks (e.g. FREAK, Logjam) against TLS?

From what I can tell, TLSv1.2 doesn't have export ciphers, so a failure to achieve a downgrade from it (assuming both client and server support it) should prevent export-grade downgrades.

Is my reasoning correct here? Is it a valid protection?

TLS_FALLBACK_SCSV fails to protect against Logjam for the same reason that Logjam actually works. That anti-fallback mechanism relies on the client putting it in the ClientHello, and being ultimately part of the input to the hash function that computes the final Finished message. This works only as long as the active attacker cannot break the handshake crypto immediately, and fix in real-time the Finished message contents. But that is exactly what happens with Logjam: the attacker modifies the ClientHello message to include the export RSA cipher suite as part of the client suites, so that the ClientHello that the server receives is not what the client sends. While he is at it, the attacker can also modify other parts of the ClientHello and the ServerHello that comes back as answer, e.g. to modify the advertised maximum version (from TLS 1.2 down to TLS 1.0) and to remove the TLS_FALLBACK_SCSV.

Things go that way:

Client sends a ClientHello that says "TLS 1.2, can use DHE-RSA, TLS_FALLBACK_SCSV".
Attacker changes that into a ClientHello that says "TLS 1.0, can use only DHE-EXPORT-RSA, no TLS_FALLBACK_SCSV".
Server responds with a ServerHello that says "ok, TLS 1.0, DHE-EXPORT-RSA, no fallback".
Attacker again changes that into a ServerHello that says "ok, TLS 1.2, DHE-RSA, your anti-fallback was seen and well processed".
Server sends the export DH parameters, duly signed, with a 512-bit modulus. The attacker let them flow as is to the client.
The client expects "normal" DH parameters, but they are indistinguishable from "export" DH parameters, except for the modulus size, and the client is totally happy with doing weak DH if the server appears to want to do it (apparently, some Safari versions even agree to use a 16-bit modulus...).
The handshake continues, using this 512-bit modulus that both client and server agree to use (though one of them thinks of it as "export" and not the other).
The attacker breaks it right away (thanks to its small size and predictable modulus), and thus obtains the session key that client and server use.
At the end of the handshake, both client and server computes the Finished messages that they should send and that they should receive. They saw distinct handshake messages (the attacker modified the ClientHello and the ServerHello) but the attacker has, at that point, the encryption and MAC keys, so he can decrypt, patch and re-encrypt the Finished messages at will to maintain the illusion.

Summary: TLS_FALLBACK_SCSV is an "anti-downgrade" mechanism, but it covers only the protocol version, and, more importantly, it works only as long as the downgraded handshake is still resilient to immediate and total breakage. This was fine for POODLE, where the attack occurs only after the handshake, when encrypted messages are sent. But not for Logjam.

As for FREAK, it is roughly the same, except that it relies on a further bug in the client implementation: the client must accept to use an ephemeral key sent by the server even though, from the point of view of the client, no such key should be sent since the client did not ask for an export RSA cipher suite (there is no non-export RSA cipher suite in SSL/TLS that still uses an ephemeral RSA key pair).

While it is tempting to state that the problem is a "protocol flaw" and lies in the fact that the export DH parameters are indistinguishable from non-export DH parameters (this is the point of view of the Logjam attack authors), my own analysis is that the true problem is the client and server both accepting to use weak crypto -- the server by willingly supporting DHE-export, the client by accepting to do some DH with a way too short modulus.


Storing sensitive info in DB with Public/Private Asymmetric keys I need to store a user's sensitive input on a website (like SSN) into a database. This data cannot be a one-way hash. The data, once input into db, will never be sent again to a website or anyone untrusted, but may be sent via the server to another trusted API so I need to be able to read it.

Let's assume that we have proper access controls, keys are properly stored/managed, and all information is securely transmitted through HTTPS.

From what I have read online, the method that seems to make the most sense is using a public/private asymmetric key encryption. So:

Generate a public/private key
Give public key to client
Encrypt data with public key on client and send to server
Store encrypted data into DB
Decode with private key when needed

Some questions:

Am I missing any steps here or misunderstanding anything?
Do I need to generate a new public key for each user on my website? Or is it okay to use the same public key every time any user is sending me an SSN?
Is it okay to store the publicly encrypted data directly on the db? Or is there something else I should do before storing it?

Thanks!

Using PKI (Public Key Infrastructure) for this doesn't make much sense if your users are actual users of your website / service. HTTPS is already doing transport layer encryption for you.

What you should do is data tokenization + encryption + compartmentalization.

A possible solution would be to setup a dedicated database and server that is separate from the rest of your application ecosystem, and use data-at-rest encryption for your database. In addition to this you can also use application-layer encryption to be extra-safe. (All this done using AES).

This database would be solely responsible for storing this PII (SSN's in your case) and therefore would associate every SSN with a random UUID that can be used in your "main application database" in liue of the actual encrypted data. This random UUID is essentially your foreign key to the sensitive data stored in the secure encrypted database.

This lets you put in place stricter ACL's and permission policies governing access to the encrypted database. For reading and writing you can have separate access policies, having separate access keys for reading and writing.


How to proceed with IoT Vulnerability assessment? First: This is not one of those "How do I start hacking?" questions, but more of a "How do I begin testing a specific device?".

It is a part of my Bachelor Thesis to perform a Vulnerability analysis/assessment of an IoT device that was Implemented during another BSc Thesis with a security focus in mind, and provide possible solutions or improvements. Applying Kerckhoffs principle, I have full access to the documentation, source code and have even been provided with a test client, leaving it to me to set up the webserver according to documentation.

How do I proceed?
According to this we have various steps for a full assessment.

Discovery
Vulnerability Scan
Vulnerability Assessment
Security Assessment
Penetration test

System
The three major thematic components are already identified:

RFID Reader/tags
Microcontroller Client, (Arduino /w Ethernet Shield)
Backend system

Additional info to provide a better picture:
1) only uses ID of rfid tag (authorisation without authentication), tag cloning/spoofing possible. Considering if it is possible to integrate this with the proprietary door locking system, as the same rfid tags are used, so the system has user authentication.

2) Arduino Uno as interface to serial port and reading rfid tags, uses crypto library to ChaCha20-Poly1305 encrypt/authenticate trafic to backend, pre-shared key, generates new session key periodically, I will implement a small programm that emulates the communication via serial port.

3) Backend with Webserver(Apache), application server (django) and database (sqlite, as its still a test system). Provides Webinterface as administrative tool, uses state of the art TLS.

Current Status

I am currently stuck on how to tackle this in a methodical and structured way/process.
I don't really have that much hope in attacking (1) as I can't really see that many attack vectors, apart from cloning/spoofing
In (2), as it is an Arduino, using 99% of its capacity for its tasks. I already used flawfinder on the source code, but it showed only a few errors (check array size if copy etc), which were all handled in the code. No dynamic memory allocation is happening, reading from arrays is strictly defined by size of arrays etc.
Assuming that the ChaCha20 Library, which brings their own secure RNG is properly implemented, I don't really see anything here.
Finally (3) where I see the most potential. Apache Webserver running on Debian 9. Webserver are quite often configured incorrectly/not up to date which opens up attack vectors. Application server? Not sure about that one. Webclient, depending on the implementation, build with Django, could also be one of the more vulnerable components.

TL;DR: I have an IoT device, consisting of multiple components (Microcontroller, backend webserver with webinterface), and I am stuck in how to do a methodically correct and thorough vulnerability assessment.

Questions

What is the proper methodical approach to this Problem? Are there standards/ frameworks?
How can I thoroughly test (1) and (2) for vulnerabilities? As there are guides for pentesting (3)

EDIT

I leave the background information as it is. Main question is:

What is a correct methodical approach to Vulnerability assessment of a multi-component IoT device?

TL;DR:

RFID Handling (your main input to the system)
Debugging interfaces (combine this with all the other steps)
Web app
Crypto stuff
Source code auditing
Side channel & fault injection (that's a kinda harder one)

1. RFID

I'd start with the RFID part (check out proxmark3). How does the arduino handle a 1KB ID? It should blow up. it might even throw up some of its memory somewhere.

2. Debugging interfaces

DEBUGGING INTERFACES. Can’t stress that enough. Check out One-Wire debugging protocol for example and my other interface it utilizes. Try to get a memory dump.

3. Web Application

Fire up wire shark or burpsuite and see what goes on. Mis-configuration is often not your biggest problem on custom web apps.

4. Crypto stuff

Keep in mind that the arduino is a low power device with horse power almost identical to carrying out calculations with pen & paper - these two with cryptography do NOT play well. Especially the RNG part. If it’s not hardware (like a white noise generator with reverse biased transistors for example) its most probably trash. Check out how every crypto that takes place is implemented, I'm sure you'll find something.

5. Source code auditing

This goes without saying, you'll have to check the source code. I leave it down there, because by the time you start checking the source code, you'll already have a very good idea on what's going on, when and why. I think that you'd already checked various bits on previous phases, but in this phase try to be much more thorough

6. Side channel & fault injection

Last but not least, I’d try faulty injection & side channel attacks. Voltage & clock glitching on such simple architectures, as well as power analysis is very easy (compared to an ARM A series processor for example).
ChipWhisperer will be of much use!
I think you even have two step pipeline so you can skip whole instructions :P

NOTE: Try to take a lot of notes during the assessment (how you did stuff, or how the system works) as well as pictures and screenshots on interesting/weird stuff. There's no such thing as "too many notes"!


Is Torrent safe for sharing legitimate files (file verification)? Does it use SHA1 or SHA256? Let's assume that a legitimate torrent file has been safely and successfully downloaded over HTTPS and perhaps even OpenPGP verification was used to verify the integrity of the torrent file.

How good are torrent clients against attackers who want to add malicious content to the download?

Does torrent clients only catch disruption due to network failure or any kind of of attack?

Does torrent clients only use SHA1 or a stronger hash algorithm, were fewer people argue whether its still secure or not, such as SHA256?

(I am NOT asking about any privacy/piracy/legal aspects here.)

BitTorrent uses a method called Chunking, in which files are divided into 64 KB – 2 MB pieces. Each piece is hashed and the hashes (along with the piece size) are stored in the torrent's metadata (the small .torrent file, or the metadata you receive via DHT). That, along with the info_hash, makes BitTorrent quite resistant to intentional tampering (poisoning). SHA-1 is used in the info_hash and to verify the chunks.

The University of Southern California has made study on the subject:

  We discover that BitTorrent is most resistant to content poisoning.

  ...

  Because the index file is distributed outside of the P2P file-sharing
  system, each chunk can be verified with a reliable hash contained in
  the metadata. This verification provides BitTorrent protocol with high
  resistance to content poisoning.


Man-In-The-Middle (SSL) attack in my case I am taking a course in a school about network security. In a experimental exercise, I was asked to install a Man-In-The-Middle (SSL) app to a mobile phone, and install a certificate(with private key inside) on the phone.

My questions:

Is the certificate used to generate a fake certificate to pretend the app(might be a proxy?) is the server which client requests for?
Why there is a private key inside this kind of certificate? What is the private key used for here?

Assuming I understood you correctly and the phone app is doing the MITM, then :

1) Yes - it is generally used as a root CA to create (on the fly) new certificates for all visited web sites.  That root CA's public key must be trusted by the browser.

2) The private key is used to sign all the subsequent certificates (for the sites), that's why it is needed.  The MITM app generates the site cert using the private key and the browser verifies it using the public key.


Would VirtualBox sandbox potential viruses from main system? I am working with several maintainers of Homebrew currently to verify that several programs in the cask library now ship from the developer with trojans. To verify the claims I created a Virtual machine in Oracles Virtualbox running Elementary OS (linux based on debian).
From there I downloaded the suspected files and uploaded them to virus total (https://www.virustotal.com/gui/file/71e362921a19923d8cd19052641718b91b8c967aa1b0f277e7732c2901a6234b/detection). I downloaded both the Windows exe file and the Mac dmg file. The Windows file came up with malware but I was unable to check the Mac version do to a large file size. Following this I deleted the Virtual Machine.
Is there a chance that this DMG, which is possibly infected, could attack my computer which is running MacOS? Clearly the windows exe wouldn't be an issue but what about the DMG?

Virtualbox provides sandboxing by creating entirely new virtual system inside your host system. Its isolates the virtual system from the host machine, any thing you do inside the VM won't directly affect your host system, unless there is some host-only communication which probably gives some worm to try to attack your host system. But as long as you did not install the infected package in the first place, it will be okay.


How should one properly dispose of a printer or fax which is used for sensitive documents? If you need to dispose of printers or fax machines that have handled sensitive documents, how should they be handled?  Should you permit them to be donated or sold for reuse outside the organization?

What kinds of media sanitization methods are recommended for this scenario?  Any references or links to industry standards would be nice.

When I worked for the .gov, the answer was to take it apart looking for storage media (which you remove and take care of).  If it's still serviceable afterwards, then off to salvage (for sale or recycling) it goes!

I'm sure that they did something different (aka, tossed it in a shredder) for machines that held the scary stuff, I don't know.


Is a PGP revocation certificate sensitive? In relation to an openpgp key on a smartcard:

Besides revoking the key, is there anything else it can be (ab)used for? Can I just ensure it's reliably stored but not worry about it's confidentiality?

What a Revocation Certificate is About

Worst case in losing access to an OpenPGP key is that it probably is published on the key servers, and you have no chance in marking it as invalid any more, it will stay there forever, telling everybody "hey, that's my key, use it".

A revocation certificate enables you to revoke your OpenPGP key if you lost access to your private key by publishing it on the key servers.

  Besides revoking the key, is there anything else it can be (ab)used for? Can I just ensure it's reliably stored but not worry about it's confidentiality?

Whoever has access to it, can revoke your OpenPGP key. This cannot be undone once published. Using the revocation certificate, no further access can be obtained: it does not included the private key.

  If I had to guess a revocation certificate is "I declare  revoked LET IT BE KNOWN! - Signed by " but I'd really like to know.

In the end, that's exactly what it is. A revocation certificate is a special kind of signature on your OpenPGP key having some "revoke" bit set.

How to Create a Revocation Certificate

A revocation certificate can be created by using gpg --gen-revoke. From man gpg:

   --gen-revoke name
          Generate a revocation certificate for the complete key.  To
          revoke a subkey or a signature, use the --edit command.

I recommend to store it both digitally in a safe place, but also print it (qrencode for encoding the ASCII-armored revocation certificate can do a great job here if you don't want to use OCR) and deposit it with somebody you know very well and trust.

Remember, even if you break up with that person, all he can do is revoking your key, not getting access to it. As you can add a description, you can even know which certificate was used for revoking your key and let the person know that to deter him.


MySQL/CGI: password in C source file unsafe? Is this line bad practice from a security stance?

connect = mysql_real_connect(connection, "host", "user", "password", "database", 0, (const char *)NULL, 0);

If so, what solution would you use?

Edit

void get_credentials(char* host, char* name, char* passwd, char* db) {
  char string_path[80] = "/etc/.acro";
  struct stat sb;
  stat(string_path, &sb);
  int file_OK = FILE_OK;
  if (sb.st_mode == 0644) {
    fprintf(stderr, "Corrupt login file: permissions");
    file_OK = FILE_BAD;
  }
  /* if(file_meta->st_uid != ???) {
       fprintf(stderr, "Corrupt login file: owner");
       file_OK = FILE_BAD;
     } */
  if(file_OK) {
    FILE *login_file = fopen(string_path, "r");
    fgets(host, 80, login_file);
    fgets(name, 80, login_file);
    fgets(passwd, 80, login_file);
    fgets(db, 80, login_file);
    host[strcspn (host, "\n")] = '\0';
    name[strcspn (name, "\n")] = '\0';
    passwd[strcspn (passwd, "\n")] = '\0';
    db[strcspn (db, "\n")] = '\0';
    fclose(login_file);
  }
}

Edit 2

The permission check should look like this for a 700 file:

// 33216 = 100700 in octal => rwx for owner only
if (sb.st_mode != 33216) {
    printf("Corrupt login file: permissions");
    file_OK = FILE_BAD;
}

Yes, for several reasons.

One, someone with read access to the binary could potentially run the strings command and look for likely possibilities near the phrase 'localhost'.

Two, if you ever decide to use the program elsewhere, you currently have the options of 1) setting up the exact same database on localhost with the exact same username and password (really unwise) or 2) altering the source code and recompiling for the second platform.

Alter the program to read its connection data from a config file in either /etc/programname/program.conf or ~/.programname/ depending on the flavor, and make it insist on having the directory permissions set to 700 and enforce proper ownership.


Can my computer get hacked if I use a local server for development only? For example WAMP? If I use software like WAMP to test and develop my PHP websites, can someone access my computer and steal data or view my in-development websites, or even hack my computer?

Yes, it is possible as long as you are connected to the internet, check your network configuration that could possibly expose the machine you're using which has WAMP installed.

Let's say for example your router is configured to port forward all ports to the IP of your machine and you also have a vulnerable version of WordPress installed inside your WAMP, the attacker can use that to run code on your machine and install anything on it.


Stack smashing protection, reordering variables So few days ago I started reading a paper about bypassing SSP/ProPolice and after I read it all I tried the bypasses but they didn't work. This is the code I used:

   int f (char ** argv){
         int pipa;  // useless variable
         char *p;
         char a[30];

         p=a;

         printf ("p=%x\t -- before 1st strcpy\n",p);
         strcpy(p,argv[1]);        // <== vulnerable strcpy()
         printf ("p=%x\t -- after 1st  strcpy\n",p);
         strncpy(p,argv[2],16);
         printf("After second strcpy ;)\n"); }

 void main (int argc, char ** argv){
         f(argv);
         execl("back_to_vul","",0);  //<-- The exec that fails
         printf("End of program\n"); }

And the compile command is: gcc -fstack-protector -z execstack -o f f.c
So basically my problem is the reordering variable that place &p and &a above their buffer so that I cannot overwrite p's address by sending a large buffer. How I could bypass this?

If the variables have been reordered so that p comes before a[30] in memory, and your only attack option is to overwrite p by overflowing the buffer in a, you cannot do it.

(At least not sensibly.  You could try for an arithmetic overflow in strcpy() by passing in a 4GB string, but it's virtually certain you'd clobber something important before you wrapped around far enough to overwrite p.)


How can I create a research botnet within VMware? For educational purposes

I am attempting to create a botnet within VMware making use of 3 or 4 machines (So I can attack a 5th virtual machine using this botnet), but the issue I'm facing is I can't find any bots or software which would allow me to accomplish this?

So far I've utilized UFONet but rather than accomplishes something like the above, it utilizes 'Open Redirect' vectors on third party web sites.

Botnets are a large and varied class of software, which do a variety of tasks, so it's not necessarily easy to provide exact examples.

With that said, if you take a typical task of creating Denial of Service conditions in the target system, then it's relatively easy to replicate the actions of a botnet with standard software.

For example say you want to DoS a web server, a standard way to achieve that is to send large quantities of traffic to the target web server port.

So to do that you can use load testing tool such as ab which generate load to a site.  Just write a script to start up 3-4 instances and see how your target fairs.

Another example of the concept would be the excellently named Bees with Machine Guns which uses Amazon EC2 instances to provide the systems to carry out the load testing.


Why would you want to run DNS servers externally? Something that's never made much sense to me is when environments have DNS servers which are publicly accessible (on the internet). This more often than not seems to leave them vulnerable to Cache Poisoning/Snooping/Amplified DoS attacks.

The only types of clients I could think of that use DNS servers externally for any good reason would be ISP's and the like
What's the reasoning behind wanting to expose your DNS server publicly?

Cheers,

When talking about DNS servers, it is important to distinguish between recursive resolvers (those servers providing clients with name resolution services) and authoritative nameservers (those servers answering final queries from local zone files).

If you are talking about recursive resolvers (DNS caching servers), then, by all means, if an organization has an intranet, the recursive resolvers should be there, not on the Internet. And if the organization does not have a segregated Intranet or internal network, recursive resolvers that permit queries from a restricted set of sources are certainly a good idea. As you say, an ISP might have a case for a wide open resolver, partly because queries for non-public names aren't expected to be handled by such a server, partly because of the trouble of listing very large amounts of permitted IP addresses, and partly for historical reasons (it's the way it was always done in the past).

If you are talking about authoritative nameservers, then one good reason to have those servers out on the Internet is for excellent response time. Every single client who wants to reach your website, your email server, your SIP server, or pretty much anything else you can think of to offer by name under your domain name is sooner or later going to generate a query against your authoritative nameserver (except if the answer has already been cached). The response time of this server is going to impact the response time of every service you offer. You want that query to go to a responsive server in a well-connected hosting centre, if possible. If you don't have servers of your own in such places, outsourcing authoritative nameservice to a DNS provider is probably a good idea. These days, almost every domain registrar also offers outsourced authoritative nameservice if you want it. I exaggerate a little bit the importance of a very responsive authoritative nameserver, but you get the message.

Still on the topic of authoritative nameservers, I should note that at least one of the threats you mention, cache poisoning, is not applicable: an authoritative nameserver is configure to not answer queries from cache. As for amplification attacks (where spoofed packets are sent with a question, the answer is larger than the question, and this answer gets directed at a victim), the location of the nameserver (behind a firewall or not) isn't going to make a difference. To some extent the nameserver has to answer those queries no matter what or else client's aren't going to find the services under your domain.

A common configuration for organizations with intranets is split DNS: there are two sets of authoritative DNS servers. One set has the public version of the zone, and it belongs out on the Internet. The other set has the internal version (which probably has a superset of the contents of the public version) and belongs on the intranet. This case is pretty simple. The public authoritative servers are unable to accidentally leak any private DNS information because they don't have a copy of the internal zone file and they can't get one since they are out on the Internet. (Obviously this assumes your zone file deployment process won't ship an unsanitized zone file out to the public version of the server during an update!)


Why VeraCrypt does not use a TPM? According to the VeraCrypt FAQ, regarding whether or not TPMs are supported:

  No. Those programs use TPM to protect against attacks that require the
  attacker to have administrator privileges, or physical access to the
  computer, and the attacker needs you to use the computer after such an
  access. However, if any of these conditions is met, it is actually
  impossible to secure the computer (see below) and, therefore, you must
  stop using it (instead of relying on TPM).

  If the attacker has administrator privileges, he can, for example,
  reset the TPM, capture the content of RAM (containing master keys) or
  content of files stored on mounted VeraCrypt volumes (decrypted on the
  fly), which can then be sent to the attacker over the Internet or
  saved to an unencrypted local drive (from which the attacker might be
  able to read it later, when he gains physical access to the computer).

Maybe I'm wrong, but the content of the RAM will never contains the master keys right? The TPM will be used like an HSM, thus cryptographic operations will be made inside the TPM, and nothing about keys will be stored in the RAM. Can you confirm me that?

  If the attacker can physically access the computer hardware (and you
  use it after such an access), he can, for example, attach a malicious
  component to it (such as a hardware keystroke logger) that will
  capture the password, the content of RAM (containing master keys) or
  content of files stored on mounted VeraCrypt volumes (decrypted on the
  fly), which can then be sent to the attacker over the Internet or
  saved to an unencrypted local drive (from which the attacker might be
  able to read it later, when he gains physical access to the computer
  again).

I'm not sure about what they call "hardware keystroke logger". Is it a sort of electromagnetic analyses (DEMA)? If so, TPM is by default protected against it.

I did preview of TPM 1.2 support for VeraCrypt UEFI.

Main idea is to set secret in TPM NVRAM under PCRs protection. It locks boot chain. So modification of BIOS and other components causes authorization deny.


What is the format of an X9.62 key? RFC8292 contains this gem:

The "k" parameter includes an ECDSA public key [FIPS186] in
uncompressed form [X9.62] that is encoded using base64url encoding
[RFC7515].

There is an example of the use of such a key a bit further down:

Authorization: vapid
   t=eyJ0eXAiOiJKV1QiLCJhbGciOiJFUzI1NiJ9.eyJhdWQiOiJodHRwczovL3
     B1c2guZXhhbXBsZS5uZXQiLCJleHAiOjE0NTM1MjM3NjgsInN1YiI6Im1ha
     Wx0bzpwdXNoQGV4YW1wbGUuY29tIn0.i3CYb7t4xfxCDquptFOepC9GAu_H
     LGkMlMuCGSK2rpiUfnK9ojFwDXb1JrErtmysazNjjvW2L9OkSSHzvoD1oA,
   k=BA1Hxzyi1RUM1b5wjxsn7nGxAszw2u61m164i3MrAIxHF6YK5h4SDYic-dR
     uU_RCPCfA5aq9ojSwk5Y2EmClBPs

The key is the k= field in the example.

This does not appear to be in ASN.1 format:

$ cat vapidkey
-----BEGIN PUBLIC KEY-----
BA1Hxzyi1RUM1b5wjxsn7nGxAszw2u61m164i3MrAIxHF6YK5h4SDYic-dRuU_RCPCfA5aq9ojSwk5Y2EmClBPs
-----END PUBLIC KEY-----
$ openssl asn1parse -in vapidkey -i
    0:d=0  hl=2 l=  13 prim: OCTET STRING      [HEX DUMP]:47C73CA2D5150CD5BE708F1B27
Error in encoding
139686682194112:error:0D07209B:asn1 encoding routines:ASN1_get_object:too long:../crypto/asn1/asn1_lib.c:91:

How do I parse this format?

Unfortunately, the X9.62 standard appears to be behind a paywall. That's fine, I don't need the full standard, I just need to read a key and pass the relevant bits of it to a library that knows how to deal with it. But that appears harder than it seems; this format is not immediately understood by the libraries that I've tried, so I'll have to do some conversion myself. That is pretty difficult if I don't know what format the keys are in, though.

It indeed is not ASN.1.

(AFAIK all) The formats from X9.62 are replicated in SEC1 free from SECG with a curve point (which is the actual public key value, excluding metadata) in 2.3.3 and 2.3.4.

The uncompressed point format, which you have, is just one octet 04 followed by the X and Y coordinates each as an unsigned bigendian integer of size determined by the field underlying the curve, which you need to know already -- usually the public key is embedded in an X.509 SPKI (see below) that identifies the curve and thus provides its field size. The compressed format, which is also common, is one octet 02 or 03 designating whether Y is even or odd (for a prime-characteristic curve, often abbreviated prime and notated Fp) followed by X only.

I've never seen any library that implements ECC at all that doesn't implement (X9.62) uncompressed point format, and durn few that don't implement compressed also. It is much more common to have a disagreement about the format for an ECDSA signature, but that's not your case.

Also note the base64url-unpadded scheme used in 8292 and 7515 is not compatible with the (traditional) PEM/SMIME base64 used by OpenSSL. The two 'extra' characters are different, and OpenSSL requires padding (if not an exact multiple of 3), and in most cases requires linebreaks. Morever the 'PUBLIC KEY' PEM type is supposed to be an X.509 SubjectPublicKeyInfo structure, called PUBKEY in the OpenSSL API (and code), including the SEQUENCE and AlgorithmIdentifier and BIT STRING wrapping, although that doesn't matter here because you didn't try to read it as a key only as arbitrary ASN.1.


Questions on SpiderOak security design I was going through SpiderOak security design.

It says:

  When you first run the SpiderOak application on your computer, a
  series of strong encryption keys are generated. The keys are
  themselves encrypted with your password and stored (along with the
  data you backup) on our servers in their encrypted form.

The encryption keys are stored on their server encrypted with user password. Just in case user password is compromised, anyone can decrypt the encryption keys stored on their server and decrypt the data as well.

SpiderOak further mentions:

  But most importantly, the keys are never stored plaintext on the
  SpiderOak server.

  They are encrypted with 256 bit AES, using a key created from your
  password by the key derivation/strengthening algorithm PBKDF2 (using
  sha256), with a minimum of 16384 rounds, and 32 bytes of random data
  ("salt").

How secure is this design?

UPDATE 2017-07-09: Thanks to those folk who have given updates regarding SpiderOak encryption keys.

That certainly reduces the risks but, as we've seen with LastPass, that doesn't necessarily eliminate it. And that's the point, you have to do your own risk and impact assessment when you store sensitive data in the Cloud. Choosing a supplier that has taken the time and money to obtain government and industry security certifications is a mitigating factor but might be more expensive.

Bottom line: if you choose a supplier with the lowest cost, you have to accept some compromises.

That approach would not seem to be the best one but it isn't that bad and certainly better than many cloud backup services do.

The best approach is for the keys to be generated by you locally so that the cloud service never has a copy. That way there is no way for the service to be able to decrypt your data.

In this case, you are having to put trust in the service that they won't and don't take a copy of the keys before they are encrypted and that their system is secure enough that the keys are protected when you unlock them.

I would say that this puts the risk at "low" given the track record of SpiderOak. But obviously, this depends on the data you are trusting them with. I certainly wouldn't consider it for highly sensitive data or really high value data. But for most uses, it would seem OK, though only you can really assess the risks/impacts for your data.


Specific security concerns with (now unupdatable) Win XP I'm trying to quantify the exact risk I'm subjecting my PC to if leaving it with Windows XP as opposed to upgrading it to e.g. Windows 7, an upgrade that would be very time-costly in my case. I don't really go on "dodgy" websites and have a firewall & AV. Is there a risk that a new exploit/vulnerability that is uncovered for XP (and not patched due to this OS's support having ceased) will affect my computer in an "unprovoked" manner, just because it is connected to the Internet, and without me accessing a compromised web resource? For instance, will my PC will more vulnerable (with XP as opposed to Win 7) to attacks from the Internet that single out vulnerable OSs, such as ping-based attacks, DDoS etc?

Using an unsupported OS will leave you at risk.  Note, that with the latest IE zero-day vulnerability released in the wild, XP was still given an out-of-band patch as about 25% of desktop users still use XP (in May 2014 - judged by internet traffic user agent strings).  However, you should not expect Microsoft to continue to patch XP in the future.

You really should upgrade to Win 7 (or Win8) or switch to Linux.  Linux will still need to be periodically upgraded, but it is often easier to gracefully upgrade, as the upgrade is free, you don't have to deal with license issues, and it is often easier to automate the process.

As for what attacks you'll be vulnerable to will completely depend on the future attack.  DDoS isn't a particularly worry - in that servers (or your home router) typically worry about that attack (and in that modern OSes don't have much protection against DDoS attacks).  Something like a ping-based attack could happen if someone finds flaws in their networking stack.  And again browsing the web very much puts you at risk, especially with tools like Flash, JavaScript, Java, etc enabled.  Even if you don't search out sketchy sites (e.g., looking for pirated software/media), its very easy to accidentally go to the wrong site (be tricked into clicking a random link).  Or an exploit on some live trustworthy website causes your browser to forward to an untrusted page.


How can I secure IP Multicast traffic? I'm interested in securing IP Multicast traffic for content that will be sent globally with several low bandwidth receivers.

I understand that simplified Broadcast encryption takes N public keys and encrypts a symmetric key N times.  This is an O(N) operation, that needs to be refreshed any time the membership of N changes.

I'm hoping that a technology is proven in either IPv6 or IP Multicast that will solve the need to secure IP Multicast problem.

IPv6 is just advanced addressing and networking protocol. With respect to Multicast Traffic and related security it will not provide any specific solution.

There are various encryption available for securing the Multicast Traffic. Cisco has implemented it in its IOS. Cisco IOS® Secure Multicast is native IP Multicast encryption that does not rely on a tunnel-based architecture, lowering administrative overhead and helping ensure optimum WAN flexibility.

Application level security and encryption can also be implied in order to secure generated Multicast Traffic. Cisco has published in depth analysis of Threats in the Multicast Environment and Securing a Multicast Network as The Multicast Security Tool Kit  you can refer that for more.


Does Google Chrome protect against cross site scripting (XSS)? In Firefox I've been using the NoScript extension to protect myself from certain kinds of malware attacks. NoScript is well known as a very powerful extension for Firefox and introduced protection from XSS and clickjacking attacks as far back as '07.

I've been looking for similar protection in Chrome, but the best I found was ScriptNo which does not specifically mention such a kind of protection (it only mentions Cross-Domain XML).

Does Google Chrome protect against cross site scripting (XSS)? (e.g. Is this passively achieved via sandboxing?)

Chrome has default protection against Reflective XSS attacks.  This is not a flaw that sandboxing can address.  This protection system works by looking outgoing requests for javascript and preventing that javascript from being executed in the http response.  No browser will prevent DOM Based XSS or Stored XSS.

Chrome's protection is the weakest when compared to the others. IE's xss filter isn't very good,  but slightly better than Chrome's.  From my research I think the NoScript is by far the best.  I have bypassed NoScript's XSS filter by exploiting content insensitivity,  and they fixed the issue quickly.  Chrome and IE still suffer from content insensitivity attacks.

Microsoft says that content insensitivity attacks against IE are "not a vulnerability" and they will never fix these issues.  Chrome has had a bug report open for this issue and I haven't seen activity for about 6 months.  So chrome might fix it eventually, maybe.  Which to be honest both of these are horrible vendor responses.  In general I find that NoScript and Mozilla have the strongest responses to vulnerabilities in their software and as a security researcher they are a joy to work with!


Why does my MacBook air have so many MAC addresses, according to my router? I am investigating some strange issues with my home network, and decided to have a look at my device history.

I only have one Macbook Air, but my device history is showing ten, all with different MAC addresses (as well as a variation in the name). The first one in the list is the correct one:

I see it's possible to randomise MAC addresses on macOS, but as far as I can tell, it doesn't happen natively, and I haven't done anything to change this - https://apple.stackexchange.com/q/282605/18070

This question was prompted by my printer randomly printing this:

After some Googling, I figured out that any HTTP request against port 9100 on my printer prompts it to print out details of the request.

The firewall is on, on the router, that port isn't accessible from my public IP address, so I figure somebody would need to be on my network to do it.

No device on my network has this particular version of curl.

Should I be worried, or is this some sort of 'feature' of macOS I'm not aware off?

Thanks

After a little research as a result of your additional information prodding.

I don't think this is MAC randomization on your Mac Air.

I believe this is someone else attempting, and failing, to break into your network.

Double-check all your security settings just to be sure.

Your known MAC shows a connection type of "Wireless", all of the others show as "Unknown", indicating they did not successfully authenticate and get an IP address on your network.

The Printer stuff suggests that your Printer is WiFi capable and may not be secured properly. If so, the printer could potentially become an access point into your network.


How to keep someone from analyzing our site? For the past days some script kiddie has been scanning our site with w3af and some basic manual checks. Although I know the site is "secure" because I analyze it almost everyday, I'm not perfect and some hole may be found.

I told my coordinator to block that IP, as he (the kid) is always attacking from the same IP, but my coordinator said that we can't do that because we don't know whether it's a static or dynamic IP, and he didn't want to prevent some legitimate user to access the site.

So what other alternative do we have to prevent the script kiddie to keep trying to find something? A WAF is not possible.

If there is no discriminating feature of the traffic that you can analyse for and block, and a WAF is not possible then blocking the IP is your only real option. Your coordinator is correct in that blocking the IP could result in you locking out authentic traffic, so the question is whether the potential for loss from the hacking attempts is greater than the potential for loss from blocking the IP.

Put together some statistics of authentic and malicious connections from that IP. If you have lots of authentic compared to malicious then it's not worth blocking it as you're going to alienate your customer base, however if it's mostly or all malicious you have nothing to lose from blocking the IP and the case is strong.


Is android keystore still vulnerable if root access is received? I studied this paper - http://www.cs.kun.nl/~erikpoll/publications/AndroidSecureStorage.pdf which states that if attacker has root access to the device it's easy to use keystore keys with another (hacker's) application. Is it still the case?

I am thinking if I should use android keystore or BKS if I will use user-entered password and I need maximum security?

An application with root access has full control over the system and can do whatever it wants to do because it can override all (DAC type *) security restrictions. So the short answer is "yes".

(*) A root user confined via SeLinux (MAC) might  be prevented from doing certain things, but that really depends on the situation. Better not rely on this.


How to load a malicious LKM at startup? How could a cracker force the loading of a kernel rootkit at boot? Is there a way to link the malicious module with another module so that it is loaded automatically without any insmod command?

Assuming you have complete privileged access to the filesystem on a Linux computer, you can load arbitrary kernel modules. There are several techniques you can use (non-exhaustive list):

Specify the module to load at boot using various configuration files.
Modify files in modprobe.d(5) to autoload your rootkit whenever a module normally loads.
Modify modules.dep(5) to specify your module as a dependency of another module.
Modify the initramfs to include your module in place of another module which is to be loaded.
Modify or replace an existing kernel module to contain your payload.

The final technique is likely the most stealthy, as it does not involve any configuration file changes and requires reverse engineering or keeping track of file integrity to detect. Note however that kernel module signing can defeat this by enforcing a valid signature on any modules to be loaded. If the module was compiled and signed on the same system as it is being used on, there is a chance that you can find the signing key in the unallocated space of the filesystem (as it is created at compile-time and then merely unlinked), but it's a long shot. If kernel module signing is in place and you are unable to obtain the signing key, you will have to find other methods to gain access to the kernel.
If you simply want to automatically load a module on boot without user interaction, you may be able to, making your desire to avoid insmod possibly superfluous. Various initramfs-generation scripts such as dracut, genkernel, and mkinitcpio are able to be used to include modules into the initramfs, and provide hooks for custom scripts. You can load the module in there.

Although not a malicious module per se, you may be able to trigger autoloading of a poorly-audited and insecure module that you have a working exploit for and use that module to escalate privileges. The two main ways to cause module autoloading is to perform a syscall with arguments that require an unloaded module (such as socket(2) with an argument that specifies the famously-insecure DCCP protocol), or by inserting a device that requires an obscure but in-tree hardware driver.


Can BIOS virus/malware be used to steal data? Since a BIOS isn't connected to the internet, even if your BIOS is infected with a malware (say you used a  usb to flash it but with files that wasn't from the official motherboard manufacturer's site). Is the damage limited locally to the functionality of your system? In that your data can't really be transmitted through the internet to another party?

Depends on the BIOS if it can connect to the internet. Most modern UEFI are able to do so, but usually don't for security reasons
Depends on the Malware. When the Malware is in the BIOS it could supply the necessary "driver" (code) to utilize your Network connection and might even implement DHCP so it get an IP and then I could probably connect to the internet and send data there.
That Malware needs to be able to understand the Filesystems (e.g. NTFS, FAT32, ext4, ...). Most BIOS are limited to only be able to read FAT32, but again your Malware might be able to expand the capabilites.

Overall it depends on the Malware, your BIOS and Mainboard. For the malware to actually do this, it would need either presupplied network code from the BIOS or would need to have the specific code for that mainboard model to utilize the network components.

Also a counter Question: Do you mean BIOS, EFI or UEFI? A malware for a UEFI would be simpler to implement than for a BIOS, because BIOS is not really standardized, while UEFI is ("Universal Extensible Firmware Interface", the universal and extensible are the issue here).

TLDR: Yes it can reach the internet, even though hard.

You can see it like this: Windows and Linux are also able to access the internet and essentially can't do more than a BIOS.

Also be aware of this: Can BIOS malware be installed from OS?
You need to install the malware first before being able to do anything.

Greetings.

PS: your malware would also need the usual IP-Networkingstack implemented. e.g. IPv4 Packets, Ethernet-Frames, maybe even DNS


Protecting decryption key on server What is the most suitable way to encrypt and decrypt sensitive data on a public cloud server disk without storing the decryption key on the server in plaintext?

REQUIREMENTS

In our SaaS web/mobile app, following user login a user may upload PDF files containing sensitive customer data to a public cloud server physically hosted by a 3rd party provider (e.g. Amazon/Rackspace). I would like to protect the data on disk by encrypting it before writing it to disk, and unencrypting it when it's read from disk.

A common solution is to use Symmetric encryption e.g. AES and to store the decryption key on the server's filesystem. I want to avoid storing the plaintext decryption key alongside the data in order to protect access to the data on disk wherever it ends up within the 3rd party's infrastructure - e.g. potentially across multiple physical servers and disks (server disks, unencrypted on daily image backup disk arrays) etc.

Conditions:
  A user should be able to download PDFs which they previously uploaded.
  An Admin user should be able to view PDFs uploaded by any user.

I'm considering using a user's login password to protect the decryption key(s).

POTENTIAL SOLUTION

During each user registration an RSA Public/Private keypair would be generated by and stored on the server's disk. The Private key would be stored AES encrypted with user's password (actually the PBKDF2 derived key based on the user's password).

Encryption:

Plaintext PDF is uploaded to server (over SSL)
Server generates a random string (R) for AES encryption.
RSA encrypt R using the user's Public key. RSA encrypt R using the Admin user's Public key. # Allows admin user to decrypt anything    AES encrypt PDF with R and
Store these three encrypted parts to the filesystem.

Decryption:

Decrypt user's Private key using their login password (via PBKDF2)
RSA Decrypt R using user's Private key.
AES Decrypt PDF using R and return it to the user

In this way if somebody has full access to the full filesystem data they cannot decrypt the PDF files unless they also know a password.

Q: Is this a secure solution? Do you see flaws in this? Are there suitable alternatives which I should consider?

You are certainly on the right track but it is possible that you're making it just a bit more complicated than you need to.  You have correctly identified that a symmetric encryption system creates the significant issue of the decryption key being present on the system.

If you choose to generate public/private keys for each piece of data, you may be making your life unnecessarily difficult in addition to "handling" the private keys in a non-optimal location.  If you are married to the data being encrypted with the user's public key, the following can be modified to store two copies of the encrypted symmetric key.  In this case it would be best to allow the user to generate a keeper and provide you with the public key rather than generating the keypair for the user.  (In other words, you really don't want to handle the private key)

In a trusted location, generate a public/private keypair for the server/application
Copy the public key (only) into the application path between the user and the database
Whenever sensitive data arrives, generate a random secret key and use this key to encrypt the sensitive data using a symmetric algorithm (such as AES)
Encrypt the random secret key with the application public key

There are a number of things that are ideal about this approach:

Backend systems and users with a business need and the proper rights can use the private key in a separate system to retrieve the sensitive data
Since only the private key can be used to decrypt the random secret keys there is no useful attack surface aside from raw brute force for an attacker who compromises the application
The effectiveness of a brute force attack is dramatically reduced since a successful attack against any of the random secret keys provides access only to that single piece of data; all of the other keys are different.  This makes a brute force attack very unattractive against the symmetric keys.
Currently a brute force against a, say, 4096 bit public/private keypair is considered intractable

So, again, you've got the right idea, but you may want to simplify your approach just a bit!


Feistel Block Cipher Can anybody explain, in simple terms, how Feistal Block Ciphers work. I am not a math student so I do not understand the math behind it, just would like the principles.

Cryptography is at least half-mathematics so you have to use a bit of mathematics at some point, if you want to understand cryptography. However, for the specific case of Feistel schemes, mathematics are not hard.

A block cipher should transform a data block (a sequence of n bits) into another block of the same size, such that:

the transform is parameterized by knowledge of some (secret) value (the key);
with the key, it is easy to compute the transform and its inverse;
without the key, well, tough luck.

Hans Feistel designed a generic way of building block ciphers. Namely, the cipher will consist of the application of several rounds, each round looking like this:

You split the input block into two halves, let's call them L (as "left") and R ("right"). Usually, you do an even split (both halves have length n/2 bits) but that's not an absolute necessity.
You compute a value S which is the result of "mangling" together R and the key K. Details of the mangling are where overall security hides, and are not part of the "Feistel structure" per se: Feistel described the overall design, not a precise block cipher. Roughly speaking, the mangling should propagate bits of R and K all over the place and should depend upon the round number. The value S must have the same size than L.
You compute the value R' as being equal to L xor S. "xor" is the bitwise "exclusive or" combination. By "bitwise" I mean that the first bit of L is combined with the first bit of S, yielding the first bit of R'; then the second bit of L is combined with the second bit of S, yielding the second bit of R'; and so on. The "exclusive or" of two bits is 0 if both bits are equal, 1 otherwise.
You define the value L' as being equal to R.
The output of the round is the concatenation of L' and R', in that order.

In simple words, a Feistel round consists in xoring the left half of the data with a value derived from the combination of the right half and the key, and then swapping the left and right halves. The Wikipedia article on Feistel ciphers has some nice diagrams.

The whole point of the structure is that computing the inverse transform (which means "decryption") is easy if you know the key. This is where there are some mathematics:

for all a, b and c, if a xor b = c then a = b xor c
for all a and b, a xor b = b xor a

(Write it down with the bit values, there are only eight combinations, so it is easy to see that it works). Thus, if you have L' and R', and the key K, then you have R (L' is equal to R); from R and K you can do the mangling again, and obtain S. Since R' = L xor S, you can rewrite it as: L = R' xor S. In other words, given the output of a round (L' and R') and the key K, you can run the mangling part again, and, with a simple xor, recompute the round input (L and R).

At that point you have the Feistel scheme. Things become complex (cryptographically speaking) when you want to know how to do the mangling, and how many rounds you will use. DES is a well-known standard which uses a Feistel scheme with 64-bit blocks, a 64-bit key, and 16 rounds (on the 64 key bits, only 56 are actually used, so the key is often said to have length 56, not 64). "Triple DES", which consists of three successive DES encryptions (with distinct keys !) can be viewed as a Feistel scheme with 48 rounds.

Luby and Rackoff have shown in 1988 that if you use wide enough blocks (say 256 bits or more) and the mangling steps consist in random-oracle like functions (think "ideal hash functions" here), then 4 rounds are enough to achieve ultimate security; however, building a "random-oracle like function" is hard (quite harder, actually, than building a secure enough mangling), and if you build a block cipher out of existing hash functions, performance will very likely be poor (hash functions are fast for processing long runs of data, but here we are talking about four hash function invocations on small data elements per encrypted block).

Most notably, the currently recommended standard block cipher, the AES, is not a Feistel block cipher.


What are the risks of using a CDN to speed up my website? How do I avoid them? Content Delivery Networks (CDNs) are well known to speed up the performance of a website, but they create the obvious security risks if someone were to change the code that resides on the CDN.

What are the security risks of a CDN?
Is there content I shouldn't serve on a CDN (e.g. javascript, raw unwrapped json results)?
If I serve javascript from a CDN, are there technical issues I could run into? (e.g. using an iFrame vs script/src and 3rd party cookies?)
Are there special concerns regarding HTTPS/SSL connections?
What information can a CDN obtain about my site (e.g. via referrer headers)?

Security risks:

Any risks that would be present on your own site.
Any risks relevant to a 3rd party site for the data you have given them.
Information may persist longer than expected.

Anything private or related to a single session shouldn't be served via a CDN -- not that I've ever heard of that happening. Anything static and non-private should be fine, including code, jscript, json data, etc.
Yes, you might run into issues serving scripts from a CDN. You should determine what issues you face via testing. However, javascript typically operates on almost anything that is part of the browser window regardless of the source domain (hence so many attack vectors and facebook ads).
No particularly special concerns about HTTPS. The CDN should have its own certificate and provide SSL service.
CDNs can determine pages visited on your site. They can determine more if you point to them using the same domain as your website (cookie overlap). That's why you often see domains like 'example-static.com' instead of 'static.example.com' -- it keeps *.example.com cookies private.


TLS/SSL and password transmission I am still getting confused with security topics. At the moment the advantages and disadvantages of some of authentication methods are still not very clear. According to OWASP Authentication Cheat Sheet, the password should be only transmitted over tls because of the following Statement:

  "Failure to utilize TLS for the login landing page allows an attacker to modify the login form Action".

My first question is: whether the statement above is automatically implicit whenever the password is not transmitted over TLS/SSL. Because normally no TLS/SSL means there is no confidentiality, integrity and replay protection for this Password but I don't understand what the form Action has to do with it. a part from the fact that there is a possibility to view the Password some where.

My second question is: Is it possible in practice for an attacker to manipulate the login form? how can the attacker manipulate the login form if he has no access to the server data..? because for instance if the entire page is programmed in php, how could the attacker do that. could you give me an example. I hope to have be more precised.

You're right: missing TLS is a far greater problem than just modifying the login form's action.  Have a look at the full paragraph from the link you provided:

  The login page and all subsequent authenticated pages must be exclusively accessed over TLS. The initial login page, referred to as the "login landing page", must be served over TLS. Failure to utilize TLS for the login landing page allows an attacker to modify the login form action, causing the user's credentials to be posted to an arbitrary location. Failure to utilize TLS for authenticated pages after the login enables an attacker to view the unencrypted session ID and compromise the user's authenticated session

As @user2313067 points out, OWASP is addressing a common misconception "that by setting https in the action of the form on an http page, you have no guarantee that the client will receive it unmodified, and it might point to a page the attacker controls. Putting https on subsequent pages but not on the login form only protects you against passive attacks"

Specifically to answer your questions:

Yes, the password is exposed if you fail to use TLS.
Internet traffic is not guaranteed to take any particular route across the Internet - one packet can go one way and the next packet can go through totally different networks. Changing the form action avoids the risk that the victim's password will go over a different network and the attacker won't be able to intercept it. Of course, this is really not necessary to understand why missing crypto is important or the basics of how network traffic interception works; it adds complexity to the particular discussion in question without need. It could be better discussed on a different page. But then OWASP is free, volunteer driven, and doesn't seem to rigorously enforce any real organization to what content goes on what page.
Yes. If network traffic is not encrypted with strong crypto then it can be modified in flight. There are two main ways to do this. First, the attacker proxies the connection between you and the server. You are now talking to the attacker. The attacker can send you anything they want. Second, the attacker sees the response from the server as it travels in the clear over the network and replaces it with their own response. Your computer cannot tell the difference between the valid response and the malicious response so it just trusts the first response it receives. The attacker pays tricks to make sure its response is received first and you get the (part of the) page returned by the attacker not by the server.


bcrypt cost 10/12/14 brute force time? Earlier I added bcrypt with cost 12 (15 is a bit too long for login, 12 looks about right).

I'm also planning to add the https://howsecureismypassword.net/ open source version but I'd rather not scare people signing up.

The default example has "calculationsPerSecond: 10 billion" -- is there any information on how many password attempts could be done against bcrypt with cost 10-14 on Today's hardware?

The most recent information I found is an Ars Technica 2012 article describing seemingly 71k/sec with better than average hardware: 25-GPU cluster cracks every standard Windows password in <6 hours -- it doesn't mention the cost used though

From 2014, hardware included

I've found a paper which looks like it contains the facts you need.

There is a table which shows the performance of certain devices corresponding to the cost factor:

Cost / Device   12        10        8         5
Epiphany 16     9.64 c/s  38.7 c/s  151.3 c/s 1207 c/s
Zynq-7020       64.83 c/s 253.1 c/s 932.6 c/s 4571 c/s
Zynq-7045       226.3 c/s 888.6 c/s 3371 c/s  20538 c/s
HD 7970         35.76 c/s 142.9 c/s 569.2 c/s 4556 c/s
FX-8120         42.93 c/s 171.2 c/s 680.2 c/s 5275 c/s
Xeon Phi 5110P  50.18 c/s 200.7 c/s 800.8 c/s 6285 c/s
i7-4770K        53.67 c/s 214.2 c/s 852.8 c/s 6615 c/s

It is worth noting that three devices, Epiphany 16, Zynq-7020 and Zynq-7045 are low-power parallel platforms. You can read more about this in the paper I linked at heading numbers 3, 3.1 and 3.2

From June 2016, hardware not mentioned.

This website shows the times to hash a password with bcrypt (and some other hashing functions) depending on the cost.

This image from the website shows the timings for bcrypt with cost values ranging from 6 - 20.

Hashes per second

Cost of 10: 14.7 hashes per  second
Cost of 11: 7.3 hashes per second
Cost of 12: 4.4 hashes per second
Cost of 13: 1.9 hashes per second
Cost of 14: 0.9 hashes per second


HMAC needed with SSL/AccessToken in place? Is using an HMAC in web service messages overkill if you are already using SSL and Access Tokens?

I’m thinking of further ways to secure a service, and HMAC message signing is one. But it comes with a cost, more complicated to implement, not as standard, etc. So I would need some really good reasons to recommend adding message signing on top of SSL and Access Tokens.

Thoughts?

SSL already provides a secure connection which protects data in transit between client and server. It ensures confidentiality and integrity, and, indeed, uses HMAC for the latter. If your security model is about attackers who might try to alter messages while they travel from the client to the server and back, then adding your own HMAC is redundant and useless.

SSL, though, is pure tunnelling. It ceases to act when the data has reached its destination. If your security model is about an attacker who may modify data stored on your server, then the fact that SSL was used to transfer such data contributes nothing to the protection against that attacker. In that setup, the actual existence of a client and a network is irrelevant; this is a storage problem, not a network problem. HMAC may help, but only if the attacker cannot learn the HMAC key, which is a restrictive scenario.

The really important question to ask first is: what can the envisioned attacker actually do ?


Simple Mail Delivery Protocol (SMDP), where is it today? what do you think of it? So I'm doing a research study on Simple Mail Delivery Protocol (SMDP)
for those of you who don't know what it is, it's a new protocol for Email delivery that promises complete anti-spam filtering.

While I was doing my research I only found one academic paper made by the students who actually proposed the new protocol (It's not really new the paper was published back in 2013), and that's it one paper in the entire world wide web!

Does any of you actually know what happened to that protocol? is it dismissed for good?

From the paper:

  ... we presented the principle of operation for our protocol. For the future we plan to develop the software to implement SMDP and operate and evaluate a
  pilot based on our design

Looks like none of this happened - or at least nothing can be found on the internet which suggests that nothing more than this purely conceptional paper was done. The authors likely moved on to other things. But when in doubt just contact the original authors.


Protecting a statistics endpoint When we download an application - it asks us whether it's ok to submit statistics, error reports to the vendor. Since this data is sent from the application to server endpoint - I am wondering how authentication works in this scenario. Is this based on a certificate that resides in the application or some agreed encryption key?

It's highly unlikely that this is a significant component of the threat model for most error reporting systems.  It's generally going to be too hard to craft fake data that will both appear to be real data to the system, and achieve some arbitrary malicious goal to boot.  It would be a lot of work for a dubious gain.

That said, there are ways you can potentially limit the impact of bad data.  For instance, you can include software registration serial numbers with the reports.   You then throw out reports that come from invalid sources (data that contains serial numbers that aren't registered to customers) or eliminate all of the data sent with a given serial number if you're getting excessive or known bad data in reports with that serial number.

So, the risk (and impact) can be limited, but it's generally not going to be worth the effort to mitigate in the first place.


How does this implementation of full disk encryption work? I have a laptop that has Sophos Safeguard full disk encryption on it. I booted the machine into another operating system on a USB stick and attempted to read the disk from the other OS, and I verified that the disk was encrypted and I could not read it. This machine does not have a TPM chip. I do not have to enter a PIN or a passphrase or insert a USB stick when I boot it up - it loads up the operating system seamlessly. Given these facts, where is the encryption key stored and how could it be stored securely?

From what I can find on Sophos website, it looks like the encryption keys and revelant certificates are stored on a mssql database which holds the information.

  The SafeGuard Enterprise Database(s) hold all relevant data such as
  keys/certificates, information about users and computers, events and
  policy settings. The database(s) need to be accessed by the SafeGuard
  Enterprise Server and by one security officer only through the SafeGuard
  Management Center, usually the Master Security Officer. The SafeGuard
  Enterprise Database(s) can be generated and configured using a wizard
  or scripts.
  http://www.sophos.com/en-us/medialibrary/PDFs/documentation/sgn_61_ig_eng_installation.pdf?la=en


Can a fingerprint be reconstructed from a device that uses it for authentication? I've noticed a lot of phones (not to mention, other devices) have built in fingerprint sensors these days.
Do these devices store information in such a way that your fingerprint could be reconstructed by someone with access to it?

Devices that support biometric authentication are equipped with Trusted Execution Environment (TEE) that stores fingerprint data in its own isolated tamper-resistant storage. The biometric sensor communicates with sensor driver which lives inside TEE. When a user wants to enroll fingerprint, fingerprint data from the sensor goes directly to the sensor driver where it is stored by TEE.

At the time of biometric authentication, TEE only answers whether the fingerprint was correct or incorrect. Raw fingerprint data is never accessible from outside the sensor driver. Hardware access is limited to the TEE and protected by an SELinux policy. The Serial Peripheral Interface (SPI) channel is accessible only to the TEE.
TEE does not hash fingerprint data because every time you put your finger differently on the sensor. The mathematical values can be used to reconstruct your fingerprint if algorithm is known.TEE encrypts fingerprint data with a symmetric key. It also signs biometric metadata that is outside of TEE and is used by TEE in validating fingerprint. So if you try to swap TEE chip with your own device's TEE, signature check will fail along with user authentication.
Even if you obtain root access on the device, fingerprints that are already stored in TEE can never be extracted. Patching sensor driver to leak fingerprint data will fail signature check of TEE image on boot and the device will brick. TEE image is still verified even if the bootloader is in unlocked and unlocked_crirical state. Emulating TEE on rooted device is still not enough to hijack sensor communication as SPI channel is bound to the real TEE.
Theoretically, you can compromise SPI channel with hardware debuggers on unrooted device to leak future accesses to the sensor but this attack is not scalable. In order to test sensor driver, some OEMs intentionally leak sensor data to testing application in prototype devices. It seems Mi forgot to disable the access for some of its production devices which is a security hole because any application can access sensor data on those devices. How this is not already violating SELinux policy is unclear.
The easiest way to reconstruct fingerprint is to copy prints from the surface. Fingerprint protection is as secure as physical protection.

Fingerprint HIDL
How does Android save your fingerprints?


Why mobile applications share device characteristics with third parties? It is known that mobile applications can share with third parties many different types of data from information about the device to search terms used in the application.

I understand that search terms are useful to businesses in order to achieve targeted advertising. However I cannot imagine how device information are useful to them.

If you could provide me with any literature that explain this I would be grateful.

Thanks

The more information third parties have about a consumer the more accurately they can profile what causes a consumer to make decisions. Simply knowing what app's are on a mobile device can reveal a lot of demographic information about the user (think dating apps, news apps, religious apps, type of games purchased, etc). Likewise the type of hardware you are using can also imply economic information (using a $1200.00 phone vs. the most popular free phone given away with two-year plans). This type of information is worth a lot of money to a variety of organizations as it can help them persuade the consumer to do things (buy things, vote on things, change the way they view a political topic, etc.) What you are asking about is a HUGE subject and the data is used in millions or ways but the following to URLs would be a good place to get some background information on it.

http://www.cbsnews.com/news/the-data-brokers-selling-your-personal-information/

https://www.privacyrights.org/content/data-brokers-and-your-privacy

BTW: a popular book which covers this information and probably provides a much more in-depth answer to your question is

Data and Goliath: The Hidden Battles to Collect Your Data and Control Your World
by Bruce Schneier
ISBN-13: 978-0393352177
ISBN-10: 039335217X


Should a user be able to change another user's role to match their own? Lets say a web application has four user roles. Standard, Supervisor, Manager and Administrator.

Should a manager be able to promote someone else to a Manager, or only to a supervisor?

I realize in the latter situation, an admin technically wouldn't be able to make any other admins, but administrators could always be an exception to the rule.

Although it is up to you, common way is a user can set other users equal to them.
There can be many admins if it is wished to be so..

Giving a lower rule is a harder case in my opinion.. I made you admin and you can un-admin me? weird huh? well...this could happen...

So yeah, I can set you equal to me, than you can downgrade me.
Thus, having only one master user is safer. Not that there can't be many, but having a lot of them may lead in to using your app/website etc...


Does changing an uploaded executable's file extension to .png render it safe? A colleague of mine has a personal website in which he allows users to upload anything within a certain size,

but before the actual upload he checks to see the file extension:

if ( $type == 'image/gif'){
  $ext = '.gif';
} elseif ( $type == 'image/jpeg'){
  $ext = '.jpg';
} elseif ( $type == 'image/png' ){
  $ext= '.png';
}  else {
  $ext = '.png';
}

He says to me, that by making all files images no harm can be done to the server.

for example :

  evilscript.evil

would become :

evilscript.png

And be thereby rendered useless.
Is there any truth to his claims?

There are basically two main ways an uploaded file can be harmful: by being executed (as a script or binary) or by being run/used in an application and abusing an exploit in it (e.g. an uploaded MP3 which is then opened by a specific player, abusing a known weakness in it).

In other words, it all depends what happens with the file after uploading. If someone is able to upload a Perl script, but the server never executes the uploaded files or even does not have Perl installed, nothing can ever happen. In general: if you make sure that the uploaded file is never run or interpreted you will be safe.

Renaming the files only helps with one thing: on some operating systems, some file extensions may be linked with a specific application. If you rename the file you might prevent that the file will be opened with a linked application. But depending on the system and setup the uploaded files might still get opened with a vulnerable application. To stay in the above example: if any uploaded file gets opened with an MP3 player, even if you rename it to song.png, it would still be able to exploit a weakness in the player (except if the player has its own layer of checking and e.g. does only accept .mp3 files).

The renamed files are not images suddenly, just because of the renaming. On Unix and similar systems, there is even the file command to analyze the type/MIME type of a file.

Bottom line: in my eyes there is only one thing you can do. Be very specific in your setup about what can and will be done with the uploaded files. Any libraries, extensions or applications accepting these files should always be updated to the latest version.


BREACH attack vs filtered reflected user input I am in charge of the applicative security of our application and would like to test our exposure to the BREACH attack.

Our django-based web application reflects filtered user-input and serves a CSRF token.

The way I understand it, BREACH exploits the HTTP compression algorithm of the response body (so our session cookie would be safe in the HTTP header) to find other instances of a particular user-input string.

But what if canary="somethingsomething" becomes canary=&quot;somethingsomething&quot as user-input? Is the canary part so relevant to the "guessability" of somethingsomething? My guess this removes the canary for automatic detection, but if the rest of the page stays the same, somethingsomething would still be vulnerable, but more difficult to identify, especially if there is more than one token in the page...

If the user input is reflected verbatim with each request, your method probably does not protect against BREACH.

The most certain way to defend django is to turn off Gzip compression.

Alternately, you can XOR the token with a different pseudo-random value for each request.


VeraCrypt/TruCrypt - I can't understand why you'd want to create a "hidden" volume...? I can't think of a reason as to why you'd want to create a hidden volume in VeraCrypt. It says because "you may be asked to hand the information," but why would I need to hand it over? Nobody has any proof of what may or may not be in that volume, so they can't claim that I'm doing something unlawful (assuming I was), because they literally have no proof of absolutely anything. Hence, they cannot make me hand over the password nor can they penalize me for defending my privacy and refusing to hand over my personal files without any proof that those files are somehow harmful (or whatever you wanna call it).
Also, if you have to hand it over, it doesn't make sense that while there is 500mb/700mb occupied space when the files there only take 300mb. Where did the other 200mb go?

...But let's focus on #1, as that - in my opinion - is a more important point that just obliterates the suggested reason, far as I can figure.

Your first question is really a legal one, and you seem to be assuming two things:

The attacker is a government of some sort.
That government actually respects citizen privacy and requires some sort of reasonable suspicion before it can force people to give up encryption keys.

Neither of those assumptions are necessarily true. For all you know, some random thief could grab your laptop while you are using it, notice a VeraCrypt file sitting on the desktop, and pull out a gun and force you to decrypt it. It's not super realistic, but definitely possible.

And even if it is indeed a government, not all countries have privacy protections or require reasonable suspicion. Even in ones that do (e.g. US and many European countries), there have been lots of cases where courts have forced people to supply their decryption keys because it is deemed relevant to an investigation. Whether they have the authority to do so is a subject of current debate, especially in the US where there is supposed to be protection against self-incrimination. Here is one such case:

http://www.cnet.com/news/judge-americans-can-be-forced-to-decrypt-their-laptops/

For your second question, try it out yourself: Create a 500mb outer volume, containing a 300mb hidden volume. Completely fill the hidden volume with files. Then mount the outer volume. The outer volume will still show 500mb of free space.

How does this work? The idea is that you're never supposed to write to the outer volume once you have created it, as doing so could corrupt your hidden volume. If you open the outer volume, even veracrypt does not know that the hidden one exists. There is no way to tell that a hidden volume exists because the hidden volume is indistinguishable from free space (which is why veracrypt still shows 500mb free space when you mount the outer volume). That's the whole idea of plausible deniability; there is no technical way to prove that there is more encrypted data.


How does Jami (formerly Ring.cx) really work, and how secure is it? Jami calls itself "ultimate privacy and control for your voice, video and chat communications". But forums online mentioned in passing (little depth) that it uses bad cryptography protocols and has messy source code. What exactly is insecure about its architecture and why are those aspects issues?

It does not look like they offer perfect forward security for either voice or chat conversations. ... They are not using a protocol like OTR or Axolotl that is designed for real time communications. ... Their description of their encryption confirms my concerns. They are not using a protocol like ZRTP to prevent MITM attacks. (link)

... other software, such as WhatsApp, Ring, ChatSecure, and Signal are not secure than you think. ... "Ring" is using SIP protocol, which is very old and not P2P friendly. They claimed it as a "decentralized"
software, and it's bulls***. (link)

Ring, on the other hand seems to want to use "established standards", which are full of loopholes that strip out security.

This does not reflect reality of secure protocols, and actual security experts typically consider "DIY security" dangerous and rely on established primitives or even protocols. (link)

Greetings, Ring developer here. Ring is a distributed communication platform, its nodes are part of a DHT network, so their IP is indeed exposed. (link)

They support crypto that is considered to be broken. https://en.wikipedia.org/wiki/POODLE Also they're patching their crypto lib – there's something deeply wrong if you have to patch the crypto lib you're using.. And no, it's not about patches itself, but about "how broken is your crypto lib, so that you have to patch it?" – ring-daemon @ 8ca874d790be92649187aabcb55fa998dae045df I'd look more into stuff, but the more I looked the worse it got. Not comparable to Tox at all.

(…) it takes a slightly different approach from Tox's by building not only on established cryptographic libraries, but also on established protocols. If that's enough (as it's being made to appear) to make it unsound security-wise... well, to put it simply, it is not enough.

Isn't it build on top of broken stuff? Namely, TLS/SSL. ... It's a matter of complexity – the more complex something is to work with, the more bugs there will be as a result. Using something as complex as TLS/SSL really helps to have buggy crypto code. IMO anything using SSL/TLS is going to be broken, be it sooner or later. One of reasons why Tox uses NaCl/libsodium. (link)

As a Jami (formerly Ring) developer I will try to answer this. Of course this answer is inevitably biased and incomplete, but it might answer some concerns or misunderstandings about how Jami works, and help to understand its architecture, and the limits of this architecture.
Building a secure distributed real-time communication platform is often a trade-off between ease of use, performance and privacy. Jami' security model is not perfect and will likely evolve, and we are open to comments, suggestions, and criticism. I will try to edit this answer to add more details if requested.

It does not look like they offer perfect forward security for either voice or chat conversations. ... They are not using a protocol
like OTR or Axolotl that is designed for real time communications. ...
Their description of their encryption confirms my concerns. They are
not using a protocol like ZRTP to prevent MITM attacks.

Jami establishes an authenticated peer-to-peer TLS 1.3 session (using GnuTLS) with PFS cypher suites enforced, typically (TLS1.3)-(ECDHE-SECP384R1)-(RSA-PSS-RSAE-SHA384)-(AES-256-GCM) is used.
This P2P authenticated TLS channel is used for SIP signaling, and temporary SRTP media encryption keys are negotiated with SIP on this  channel. This means that real-time communications on Jami (audio and video) are PFS and end-to-end encrypted. However Jami doesn't offer other guarantees like repudiation.
In "classic" (server-based) SIP, negotiating media keys in SIP is an issue because SIP servers can see those keys in plain-text, breaking end-to-end encryption and allowing MITM attacks. That's what ZRTP solves, by performing DH key exchange on the RTP (media) channel. Using SIP on an authenticated P2P channel makes using ZRTP unnecessary.

"Ring" is using SIP protocol, which is
very old and not P2P friendly.

The SIP protocol can be used for P2P just fine, in a similar way that one can use HTTP for P2P communications, and it's an established and robust telephony protocol, even if it's not perfect and some people prefer XMPP or others.

They claimed it as a "decentralized"
software, and it's bulls***.

Jami is fully distributed, which is stronger than decentralized, by using OpenDHT (a Kademlia distributed hash table similar to what's used by Bittorrent) to find contact IP addresses, which are stored on the DHT in the form of encrypted ICE candidates, used to establish the authenticated TLS P2P channel. Usernames (name<->public key mappings) are registered on a distributed blockchain (Ethereum contract). To my knowledge, no other real-time communication system provides that level of distribution.

Ring developer here. Ring is a distributed communication platform, its
nodes are part of a DHT network, so their IP are indeed exposed.

That's a downside of using a distributed network: DHT nodes IP addresses are exposed on the distributed network, which is a valid privacy concern. The current design doesn't allow to cryptographically link DHT nodes with Jami public keys and we work to make this separation as strong as possible.

Also they're patching their crypto lib – there's something deeply wrong
if you have to patch the crypto lib you're using..
Isn't it build on top of broken stuff? Namely, TLS/SSL. ... It's a
matter of complexity – the more complex something is to work with, the
more bugs there will be as a result. Using something as complex as
TLS/SSL really helps to have buggy crypto code. IMO anything using
SSL/TLS is going to be broken, be it sooner or later. One of reasons
why Tox uses NaCl/libsodium.

(comment above made by a Tox developer)
We don't "patch our crypto lib"; when a bug or vulnerability is found, the library is updated.
We live in the real world where no crypto library (and no library in general) is perfect. With time, every crypto ends up being broken - that's not a prediction but an observation.
TLS complexity is a downside, however an advantage is the ability to negotiate cyphersuites, so when a cyphersuite begins to be considered weak, transition to new cyphersuites can be done gracefully, without breaking existing implementations.
Libsodium (NaCL) is a great, high quality library but is not directly comparable to TLS. NaCL provides elementary crypto building blocks, while TLS is a protocol that performs the whole thing: authentication, key exchange, encryption etc. in a way that is standard and very well reviewed.
When building Jami we tried to not reinvent the wheel as much as possible, to avoid the risk of adding vulnerabilities.
Instead of building our own protocol using libsodium, we preferred to rely on TLS, and focused on using it the best possible way.


A new Facebook password reset bug? Based on this and this articles, the writer claims to be able to compromise about 2 millions accounts by using reset code feature, and brute forcing the 6-digits reset code.

I have to main questions about that regardless of the truth about the attack:

Is making the reset code much bigger will help resolving the problem, or Facebook will need a new reset technology?
How to defend from this attack, should I reset it again after I receive the reset message from the attacking process, or should I reset via mail?

Edit:

Credit: @Dog eat cat world.

Just to clarify the problem,the attacker instead of bruteforcing users with a certain reset code, he's bruteforcing the code to a large scale users.

The weakness here the lack of Entropy in the password reset code.

I mean that you choose a random 6 digit number(338625), and try it against many users. So the attacker has to guess a reset code from 10^6 possibilities.At some point it may work.

Calculation: Since Facebook has a large user base and receives large number password reset requests say 10000 (10^4) in 3 minutes before they expire , which is comparable to 10^6.

The probability that this password rest code is valid against some user is 0.01 .

  Is making the reset code much bigger will help resolving the problem,
  or Facebook will need a new reset technology?

Facebook can simply fix it by increasing the entropy of password reset code.
This can be done easily by :

Having Alphabets( [A-Z|a-z]- 52),Digits( 0-9-10),Special characters(say 10 ) in the password reset code.
Having a good length of say 10 characters (Answer by Rоry McCune).

Calculation: For a reset code of length of 6,the attacker now have to guess a reset code among (52+10+10)^6 .

The probability that this reset code randomly chosen by attacker matches a valid password reset code among the above 10^4 is 0.000000071 or 7.1*10^-8. Instead of doing this, the attacker have better chances of guessing password itself and trying it against many users.

  How to defend from this attack, should I reset it again after I
  receive the reset message from the attacking process, or should I
  reset via mail?

I think efforts to secure against this attack should come from Facebook.

Since, users may not look in to the reset message/email as soon as it arrives. From user point of view all i can think is of enabling Two Factor Authentication.


Internal process to recertify DMZ zones How would a DMZ zone recertification process look like? Say we create a separate security zone for each application hosted in DMZ. Now we would like to get in touch with the person in charge for the given zone to ask if it's still needed. How could this be handled? Are there any ISO 27001 directives related to this?

What you are asking for is basic lifecycle management:

Design
Deploy
Maintain
Review
Decommission

You need a policy and a procedure to review all the firewall configs (including the zones) to ensure that the current 'design' is meeting the needs and goals of its intent. The frequency of this review is up to the needs of your organisation, yearly might be fine.

Each 'zone' requires an 'owner' who designs and drives the controls in this zone. Any changes to the zone require the owner's input. Ownership is set up as early as possible to prevent the owner being surprised that they are responsible for critical infrastructure.

During the review phase, each relevant element of the zone is verified by the owner as being current, and the verification is challenged by an outside party (GRC, Information Security Steering Committee, etc.) as being accurate.

Once verified or modified, the zone returns to a 'maintenance' state. If the zone is deemed redundant, a decommissioning phase is initiated which defines and tests the removal of the zone in order to ensure a complete and secure decommissioning with minimal impact to the organisation.

As for ISO 27k, the terms you are looking for a 'controls review', and there is a whole document about this: ISO 27008


Why are card associations launching RFID enabled payment cards despite of their being unsecure? You can use applications to get data from these cards. I got tracks data of my cards as well as card number and expiry from my debit card just by single tap of phone. A criminal can use that data and use it ( though my card is DDA and only one time he can use tracks data but even with card number and expiry he can pay on many websites) . I can't understand why banks are forcing these cards despite of the fact that they are less secure.

Many people use cars on a daily basis, even with the number of deaths on roads worldwide. So why would everyday people want to use them?

The reason why I ask that question at the start is because it will get you into the mindset of Information Security. Nothing is secure everywhere, all the time. The same applies to cars, they are mechanical devices that have physical flaws, and as time progresses, virtual ones as well.

"Tap" payment schemes came about because of the wear issues associated with "Chip and PIN" technology. Due to the shear number of cards being put into a card reader at a retailer, the cards and machines become worn out. This is not only because of the physical contact required, but also dust and dirt which is just an everyday thing. "Tap" or RFID payment schemes overcome this because there is a belief that if small purchases are done with RFID, the cards and machines will last much longer. You may wish to consult your credit card company for their analysis on this topic.

At least my understanding of the current system, while it is certainly correct to say the system is "broken", there are certain features that mitigate risks.

The first is a payment limit. Many cards limit how much can be purchased by RFID or contactless transfer. As I bring up the previous point of small purchases, there is huge risk involved for everyone with large transactions (thousands of dollars). I'm aware that my card with a recent contactless terminal will not allow for a transaction over $100 to be processed, it must be done with the Chip and PIN.

The second is that the "keys" associated with transactions expire. I've seen various bits of information where some state that it's possible to clone a rfid card, but you would be unable to use it for another transaction. Other sources mention the fact that the clone will work until the true user makes another payment. Regardless of what the case might be, there doesn't seem to be any clear innovation coming down the tubes for a while. The easiest way would be to still provide a PIN, but again, removes the end-user convenience, and you might as well just use the Chip and PIN technology.

To be fair, the likelihood of someone bringing a crafted device to capture RFID payments is fairly small. Because of the close proximity involved, one would either have to physically take possession of the card, or bring such a large antenna (and/or power supply) making such a thing impractical.


Account lockout for inexistant accounts I am starting to implement an exponential backoff system to lockout accounts after a certain amount of failed attempts (1min after 5 fails, 2min after 10 fails, etc.). However, as this source suggests, attackers can detect account existence, using the fact that only legitimate accounts are locked after too many failed attempts.

My fix would be to also lockout non-existent accounts, by keeping a list of accounts name with number of failed attempts, reset regularly. This way the system will not reveal any information about accounts existence. Does this seems like a good solution?

If not, what would you suggest?

Account Lockouts can be a bad idea

Imagine you have the user bob, who has an account at your awesome service. Now Eve wants to be malicious, and lock Bob out of his account.

She sends an invalid login request, then another, then another, and repeats that process until she receives the message that the account bob is locked for a while. Then she repeats this process again and again, until bob is locked for all eternity.

Bob on the other hand would like to log into your awesome service, and gets a confusing error message that his account is locked. He contacts your support at your expense, and they inform him that there has been malicious activity (and helpfully advise him to scan his computer using anti-virus software). After Bob has wasted half an hour of his time, he attempts to log in again, only to find that Eve has still locked his account.

You might ask why on earth Eve would do that. The motive can be manifold:

Blackmail (give me money to get your account back)
for teh lulz
Getting Bob to use Eve's even more awesome service instead
etc...

How to do it instead

What you really want to prevent is online brute-forcing through automated means. Instead of locking the account, consider using a CAPTCHA to verify a human on the other end of the connection. You could also slow-down responses to login attempts to several seconds. This way, Bob would only have to wait a few seconds instead of not being allowed to log in at all.

If you want to go really big and fancy, try to do some behaviour analysis. This will cost you big time, but it does prove to be a useful aid when trying to determine if a login attempt is potentially malicious or not.

What about non-existent accounts?

So far, I explained why account lockouts are a bad idea. But if you really really have to implement them (e.g. because of customer demand), then you should also "lock" non-existent accounts.