Developer requests dev systems don't have .Net patches applied Looking for some guidance on an internal discussion we're having.
We have a .Net developer that is requesting all development systems with Visual Studio installed don't have .Net updates installed. The reasoning is that it breaks Visual Studio and things (I'm not clear on exactly what things) go 'missing' or no longer work.
Some examples of the patches they're keen to avoid:

Security Update for Microsoft .NET Framework 3.5 on Windows 8.1 and Windows Server 2012 R2 for x64 (KB3127222)
Security Update for Microsoft .NET Framework 3.5 on Windows 8.1 and Windows Server 2012 R2 for x64-based Systems (KB3072307)
2017-09 Security and Quality Rollup for .NET Framework 3.5, 4.5.2, 4.6, 4.6.1, 4.6.2, 4.7 on Windows 8.1 and Server 2012 R2 for x64 (KB4041085)

I haven't had much luck finding specific guidance around development systems, so some advice would be appreciated.

If you need to run permanently unpatched/outdated systems for any reason, at least create isolated/firewalled subnets and restrict access of these systems to other systems and information to mitigate a possible infection and restrict the use of network service on these machines.

that would include limiting the code stored on the machines to the information absolutely needed.

Which brings us to why we would have these:

The customer asks us for it

The usecase requires it (e.g. we need to test against an unpatched system, since the system it will be deployed on is isolated and wont receive updated not relevant to specific issues)

It really breaks something

A final remark:
Sometimes registry settings may be changed, and in most cases Windows allows to do an specific activation of non-secure features (i think windows 10 would still be able to talk to an early smb server if you deactivate enough stuff). In my opinion it is much better to try to achieve the required functionality by patching completely and having a setup script/ .reg file explicitly addressing the "things" which are broken by the patch/update. This also enables a much better documentation and reproducability of what is actually going on (will take more resources, though).
If you visual studio installation is so brittle that it if broken by upgrading, there is a problem.


Is this a security threat? So at my business our receipt printer randomly printed some questionable looking data.

I looked into scanproxy.net and it's clearly not something legitimate.

Can anyone give me a better idea of what's happening here?

GET http://www.scanproxy.net:80/p-900.htm
1 HTTP/1.0
Content-Type: text/html
Proxy-Connection: keep-alive
Host: www.scanproxy.net
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/vnd.ms-powerpoint, application/vnd.ms-excel, application/msword, application/x-shockwave-flash */*
Accept-Language: en-us
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; KuKu 0.65)
Authorization: Basic 0g==

All but one computer in the network are machines running OS:X - 1 Windows XP machine.

Customers sometimes connect to the network when they visit, so this might be such a situation.

What should be my next step?

Thanks so much!

Anyone able to use your printer is a vulnerability.  This is a resource that should not be exposed to public networks.   I suspect that "scanproxy.net" is well... scanning for proxies.   Its likely that they connected to an open port and tried to proxy a GET request for http://www.scanproxy.net:80/p-900.htm,  but instead this was interpreted as data to be printed.

Conduct a full port scan (0-65535) of your network range from an external node. Close any unnecessary ports.


Problems with undefined password requirements An annoyance of mine is when websites try to force me to use characters or a password policy that makes it difficult for me to remember (e.g. a number, lower-case, upper-case, special char, 5 - 10 characters)...

What would the pitfalls be of simply having a password strength calculator and only allow passwords that are "strong"?

For instance, maybe one person only likes using words so you could allow "thehorselikestodrinkwater", since it's length makes it strong, but also allow "!Pf-4", since it's complexity makes it strong.

The problem is the programming complexity. Testing for the presence of mixed case, numbers, and punctuation is extraordinarily simple.

Testing password strength in the real, practical sense is surprisingly difficult. What you really care about is whether or not that password will get cracked, not how many special characters it contains. The password apwyfzsdjn is dramatically more secure than Baseb4all!, even though most password testers will prefer the latter.

The project zxcvbn is a Javascript-based password tester that attempts to do reasonable password strength analysis based on complexity and (more importantly) dictionary lookup, and certainly does a better job than the "must contain punctuation" sort of testers.

But it's a hard problem to solve.


Damage of a leaked ETag I've read multiple times that leaked ETags from Webservers are considered an information leakage vulnerability.

For example in the server response headers:

ETag: X/"1234-56789"

But I have not found a reason why this is a problem or how this may be abused.

Of course any additional information that is not required for the application to function should be redacted, but what's the damage a a leaked ETag (therefore inode) can do?

Edit: Rapid7 for example see's this as with a severity of four.

The ETag header is used for effective caching of server side resources by the client. The server send an ETag header in the HTTP response to some string and the client caches the response content and associates the string given in the ETag header with it. If the client wants to access the same resource again it will send the given string within some If-None-Match header in the HTTP request and the server will only return the full content if the resource has been changed and otherwise tell the client that the cached content can be used. See Wikipedia for more details.

This means, that every client can get such an ETag header from the server, i.e. the value of the header is not secret. Thus contrary to your question the leakage of such a header itself is not the problem.

The problem is instead if the value of the header (i.e. the string) provides information about the server which should stay secret. Often the value of the header is just a hash over the content of the resource which is not a problem at all. But for example the Apache web server can base the ETag on the inode number, last modification time and/or size of the file. Using these meta information a unique ETag can be created much faster compared to computing the hash of the content. Only, at least the inode number is considered internal information to the server and should not be exposed to the client. While not be usable in attacks directly knowledge of lots of inode numbers can be used to gain for example information about the underlying file system which might help in further attacks against the server.

This means that the inode number should not be extractable from the ETag header because it should stay secret. This was fixed with Apache 1.3.27 (long ago), i.e. the inode number is still used to compute the ETag but in a way that it cannot be extracted from the ETag value.

  Edit: Rapid7 for example see's this as with a severity of four.

The CVSS score is computed from several parts. The details for this specific problem can be seen here but it essentially boils down to that it is trivial to use, can be done over the network, needs no authentication and provides some internal information about the server.


Advice for writing my first application security review I wish to write a security review for a specific windows server/client application that runs on a closed LAN or WAN (between 1 and 200+ users across multiple sites); it's not a web-application. The application is widely used (market-leader) within a sector in my country and the information stored within the application is very sensitive.

The types of issues I've already identified are:

Using a default database username and password (full admin access). This login is kept in plain text within the application folder.
Storing user passwords in plain text within the database
No complex password requirements
Users having access to tools within the application that can run SQL queries (with full privileges; despite their own application level privileges limitations)
A HTTP server service running on all client machines that responds to API requests. No user/password required.
Default file share with all application files including the file containing the database/username/password
Auditing information of user actions (that can be easily altered/deleted/masqueraded - see any of the above!) that have been used as evidence within million-dollar fraud/legal/HR cases

I haven't even looked at things like buffer overflows, SQL injection etc; but a colleague has offered to help me with this.

As I'm a bit new to this; I'm thinking that this would be a technical review (similar a published journal article) un-requested by the vendor? Larger users of this software often secure it as best as they can; I suppose I could write a "hardening" guide instead?

Can anyone provide me advice:

Any general advice based on the above?
Should I write a security review or hardening guide?
Are there some good examples of similar types of reviews? (I can find so many web-application reviews; but not so many application ones - however a couple of the SCADA ones were useful

Thanks!

Any general advice based on the above?

Talk to the people who may be hurt by a potential attack on the system: either directly or indirectly. Understand what their concerns are and let them know that you will do your best to protect their records and their privacy. As a security representative your job is to protect assets (personal data, etc) against threats. Your best security-focused solution will emerge once after you understand what you are protecting.

Look for vulnerabilities, but don't get too detailed. There will always be a very technical complicated vulnerabilities, but in a lot of incidents it is the relativly simple vulnerabilities that are exploited. You will get little criticism for missing a vulnerability that requires a highly skilled sophisticated attacker but you will get a lot for missing the simple vulnerabilities.

Think about operational security. In a mostly closed system the insider threat is a  significant concern. Job rotation is a great method where practical. Look for ways to segment or break up the data so that if there is a breach or leak that the damage is limited.

  Should I write a security review or hardening guide?

I think you should focus on the security review. There are security resources for the various versions of windows, and I hope there are competitant administrators running those windows systems.

  Are there some good examples of similar types of reviews?


Should I generate a lot of random serial keys and pick one for each registration or generate 1 for each user? I'm talking about Online activation. My current workflow is:

User pays via paypal (without registration)
Paypal performs a request to my API.
My API returns a serial key to the user.
Then the user is able to register using this serial key.

Is a "pay to register then use" and not a "register then pay to use".

So the question is:

Should I generate (let's say 100) keys and store them in DB then pick the first one available when someone pays via paypal? Isn't this vulnerable to "guess" attacks?
Should I generate 1 random key each time a user pays via paypal? Can't this approach generate 2 equal keys? I mean I have no info from the user except what paypal tells me so I should somehow use a random function OR loop the entire table comparing the serial keys.

Randomness and uniqueness are different concepts. Few random values from a large entropy space are generally all different but there is no guarantee on that. If you need both, I would split the key in two parts: one would be a simple sequence (uniqueness is guaranteed) and the latter would be produced by a random generator.

The size of those parts depends on your requirements: estimated number of keys give the first part, robustness to brute force attacks give the second one.

If the size of key must be limited and if you still want high brute force resistance, you will have to only use a random value and store all produced ones. Then when you need a new one, you just loop on random values until you find a unique one.

IHMO producing a bunch in advance or one at a time is just an implementation detail. If you realize that producing a new key could take too much time and lead to poor performances, it can make sense to always have a small number of keys pre-calculated in the application. You could use a background thread feeding a queue here...


What are the security implications using a Refresh Token in a SPA using Authorisation Code Flow + PKCE I am considering moving my SPA from Implicit flow to Authorization Code + PKCE extension.

This new flow will provide the SPA with a Refresh Token that doesn't expire.

Let's say a malicious user on the computer/browser manages to get hold of the Refresh Token from the browser.

What are the remediations I need to set-up on the IdP and other systems to impersonate my SPA and indefinitely exchange the Refresh token for a new pair of Access Token and Refresh Token?

I've looked around and have found no clear explanation on this matter.

Thanks!

Spec-compliant authorization code grant does not issue refresh tokens, that's one of many reasons why it's recommended. (Implicit grant also does not issue refresh tokens). With authorization code grant you're supposed to obtain a new access token without a refresh token by either relying on the existing authorization server session and performing the authorization code grant redirect again or via an iframe a la OpenID Connect.

The overall topic of protecting a refresh token is well documented in oAuth 2.0 Security Best Current Practices (BCP).


should ~/.cache/keyring-* be cleared? I am using gnupg 1.4.15

ls ~/.cache/keyring-* shows many keyring directories.

GPG_AGENT_INFO variable is pointing only to the latest one.

Should I manually delete all the other keyring agents? Is it a security risk to have all those keyring directories remaining in ~/.cache/ ?

Also, what is the correct procedure to clear/stop the keyring agent and thereby make it forget all the passphrases it is remembering.

A GPG_AGENT is a program that when asked, (de|en)crypts the data for the caller (in this case using gpg). The 'files' you see are most probably sockets for communicating with the agent.

Once the program is closed (or locked), it can't be used, those files don't contain any private information, agents are (generally) pretty-well designed, and won't even store private material out of ram (in most cases, the OS may not allow memory locking, or if you hibernate the computer, the keys can go into disk).

In regards to your question

  Also, what is the correct procedure to clear/stop the keyring agent and thereby make it forget all the passphrases it is remembering.

You don't specify which agent you are using, the basic approach is to kill the agent process, but it will probably support unloading the keys / being put into locked state. See also
How to lock a unlocked GNOME Keyring?

¹ See if the first mode character is s, eg.

  srw------- 1 indiajoe indiajoe 0 jun  8 21:57 agent.1234


Deploying a campus WiFi network that authenticates against an AD LDAP We are looking to deploy about 15-20 Cisco 1131ag access points on campus. I have been reading up on different authentication methods, but I don’t know what will be the best long term solution that allows for a balance between simple management and future expansion.

The first option I have considered is to use Cisco ACS for Windows because we already have the server so that will save some money.

Also some people recommend setting up a radius server such as free-radius on a Linux box and tying that into the existing LDAP for end user authentication this is also a money saver since the OS and free-radius are free to use.

I personally feel more comfortable in a Windows environment but I am no stranger to Linux when I have been required to use it in the past. I just wanted to get some thoughts on what is the best solution for management. Or if there is a better solution all together I would love to know about that as well.

Most places use radius in combination with a backend authentication system.

Freeradius could do the job and integrates with Active Directory: http://wiki.freeradius.org/FreeRADIUS_Active_Directory_Integration_HOWTO

Cisco ACS can do the job and also integrates with AD, though in my experience this can be cludgey.  It supports policies and of course can be used to provide TACACS AAA services for cisco devices as well.

Microsoft has been pushing NPS with their Network Access Protection http://msdn.microsoft.com/en-us/library/bb892033(v=vs.85).aspx it has the whole "call microsoft" benefit and negative.  It's supports policies similar to ACS and you can send people to get trained on it and does the RADIUS job too.

Really if you're in the EDU space you can get Microsoft licenses cheaper than a ream of paper I'd recommend going that way.  Cisco and Microsoft basically give you the same "one throat to choke" even if they're not perfect, they do allow you to easily receive vendor support.

In the same vein I'd say if you're in the private space stick with ACS and save your money.  As long as you've got a robust ACS infrastructure it's a single place to manage it all, and you've already got the license.


Is it safe to manually patch bugs on an outdated operating system such as Ubuntu 10.04? How do I manually patch security bugs safely without damaging the system for information security purposes on my Ubuntu system that I am running on one of my mobile computers? I need to find packages for armel only. I am running Ubuntu 10.04 LTS.

Here is my research into how I can manually patch security bugs:

Make list of all security bugs from Ubuntu security notice website and
write down name of packages to download and install for armel manually in the terminal.

Find all necessary dependencies and write out an organized plan to safely install proper dependencies as it may damage the outdated system since backtrack 5 is basically Ubuntu 10.04.

Manually patch the basics such as the openssl heartbleed bug with the new openssl and manually patch the glibc bug with the newer package for armel by simply downloading the packages and manually installing them on the terminal.

I must be able to run this outdated version of Ubuntu 10.04 LTS on my device since my kernel is outdated so is this the safest route?

I've been maintaining a private fork of a CMS for approx. 7 years. The initial release had some serious security issues which did not get fixed properly by the original vendor in time. This is why I have fixed it myself and this is where I have lost the compatibility to most of the original patches/upgrades.

This is possible, it takes a lot of time. And it might make sense if you want to do this for a limited amount of time - For example to prepare a solid substitution of an outdated environment. But if you are thinking about supporting the old platform for infinity, you are going to die old, angry and sad.


How to send a fixed size encrypted message to be broadcast to multiple (known) recipients without letting the broadcaster decrypt the message I am creating a network with three layers. A sender layer, A gateway layer, and a Receiver layer; each having different platforms. See diagram below

All platforms have published their public keys on a trusted public database server (not shown on the diagram).
A sender S wants to send a message to the receiver layer but it can only send the message via one of the platforms in the Gateway layer. Let's call it G.
The message contains a public section that can be accessed by anyone and a private section that should be accessible only by the receiver layer. Something like below
{
    "public"  : { <public data>  },
    "private" : { <private data - encrypted> }
}

Every time S sends a message to G; G uses the public section of the message to verify the authenticity of the sender and to identify a subset of Receivers { R1, R2 ... Rp }  where p <= n; and broadcasts the message to the "p" receivers.
How does S encrypt the message such that only {R1, R2 ... Rp} are able to decrypt the message and not G?
Some additional forces that exist are as follows:

Sender platforms layer can have 1-100000000 independent devices each having its own key pair
The gateway platforms could range from a 1-500 platforms
The receiver layer could have 1-10000000 platforms each having its own key pair

Any ideas on how to achieve this? I can do this using two Gateways, G1 and G2 where one G1 broadcasts the public key of S and G2 broadcasts the message. The receiver can check if the broadcaster of the key is different from the broadcaster of the message and return an "INSECURE_TRANSACTION" error of sorts. But is there a way to make it work using only one Gateway? Any help would be appreciated.

If I understand your question correctly, what you are describing boils down to sending an encrypted message to multiple recipients.
The way this is typically done is that the sender randomly generates a single symmetric key, and encrypts the message using that key.  Then the sender encrypts that symmetric key with each recipient's public key.  The message is broadcasted to all of the recipients, along with the all of the encrypted symmetric keys.
This way, the network is not sending N different messages to N different recipients - the same message is broadcasted to all recipients.


Tools/methods helping to determine application/protocol serving specific port I do blackbox testing of the server and figured out that there is a bunch of listening ports. I need to determine what services/protocols those ports are used for.

What I've tried so far is to use Armitage (as far as I've understood it runs some Metasploit discovery modules against commonly used ports, like port 80 for http) and it managed to determine the purpose of a couple of the open ports.

However, there are a lot of unknown ports left.

So, what more can I do to discover what applications (services/protocols) run on the rest of the ports?

The short answer is that you need to talk to the port to see who answers. Two things can come from this:

banners
protocol traffic

The problem is that banners can be faked, so you need a tool to analyze the traffic in order to get an accurate picture.

Tools:

netcat/nc/ncat - useful for basic banner grabbing
sbd - like nc, but encrypted - useful for basic ssl-based banner grabbing
nmap - the king of service detection (use -sV)
wireshark - in-depth protocol analysis with some built-in features (use when using the other tools)
scapy - for really in-depth raw protocol analysis
amap - an application mapper
other focused tools for certain protocols like httprint

Metasploit has a long list of service scanners, but they are best to supplement a more direct service analysis. I highly recommend that you shift away from Armitage until you have more experience with the tools above and with the msfconsole. Then, Armitage can improve your productivity.

Other Methods:
The more efficient method is to ask the target operating system what it is running. If you can query SNMP, you might get a service and port list handed to you. If you have shell access, you can run commands to list running services.

Pro Tips:
Be careful that the tools you use don't simply lookup the port number in a table of common services. It is easy to run services on non-standard ports. Also, make sure you scan over the entire 65,535 port range in both TCP and UDP. Some tools, including nmap, improve performance by only checking the most common port numbers, which means they can miss common services running on non-standard ports (ssh on port 8022, for instance). Warning: UDP scans can take a very long time.


Storing passwords in text files inside Ubuntu encrypted home directory I'm interested in getting offlineimap working with my Gmail account so that I can read my emails while offline. My biggest concern with this is that it's a pretty big workaround to get the .offlineimaprc file to be encrypted so you're not storing it in plain text. However, I have enabled home directory encryption, so unless I'm logged in, the file should be encrypted.

I guess that brings me to the question: is this good enough? I'm fairly security-conscious, and don't want to do something stupid and leave myself vulnerable. I lock my computer when I'm away, or I shut it down. Is home directory encryption enough to keep my .offlineimaprc file secure from most malicious attacks? Or is there some big vulnerability I'm not thinking of?

Home directory encryption only helps when you are not logged in, right? So that protects you from physical device theft.
But many of threats also happen while you are logged in, like malware?


ALFA AWUS036NHV - Monitor Mode I have recently come into ownership of the above product and was wondering if it is possible to enable monitor mode on said device? I figured this community might have a definite answer, if not a clever work around.

Apparently As of December 2014, the common driver for this device does not support monitor mode on Linux. Kernel.org showed that monitor mode was untested however I did find this link https://wikidevi.com/wiki/ALFA_Network_AWUS036NHV


How often should the DHE p and g factors be recycled? I've been asked to enable DHE in our SMTP product. I'm stuck on this question:

How often should the product regenerate its DHE p and g parameters?

I've seen some implementations that use a cron job to regenerate p and g once per day; others (e.g., Postfix) set p and g as source code constants. The most common approach seems to be once at install time.

If I understand it correctly, even if p and g are known to an attacker, recovering the encryption key means solving the discrete logarithm problem. From that I would infer that generating p and g at install time is more than adequate. But I also saw media reports about a year ago suggesting that the discrete logarithm problem might be solved by the end of the decade; that would suggest regenerating p and g regularly might be prudent.

So p is the modulus, and g is the generator.  You are absolutely right.  p and g are publicly known values, and the discrete log problem needs to be solved to break the Diffie-Hellman exchange.

Ephemeral Diffie-Hellman

The whole point of Ephemeral Diffie-Hellman is to provide for Perfect Forward Secrecy (PFS).  Here's an answer I already wrote up on DHE and PFS for more information.

Generators:  These are generally fairly small.  A protocol like SSH will allow you to exchange the group (RFC4419), but there are two standard values used for SSH; 2 and 5.  If you like math stuff, here's an explanation on generators in DH.
Moduli:  A modulus for DH is a large prime

These parameters need to be generated only once by the server for each size that you're looking to support.  I would use OpenSSL's functionality as it's described in their wiki.

Here's OpenSSL's Wiki on DH Parameters.

This article linked to in that wiki gives good information on PFS, and configuring your SSL/TLS enabled server to use it.  You need to make sure your server has a version that supports it, and put the PFS cipher suites (DHE and ECDHE) at the top of your list.


How can I identify open DNS resolvers in my network? This article highlights how open DNS resolvers are being used to create DDOS attacks across the internet.   How can I identify whether any of our DNS servers are open?  If I find that we are running open DNS servers, how would I close them to prevent them being abused for DDOS attacks?

An Open DNS server is one that answers DNS requests from anyone for anything. As a general rule, the DNS servers you run should only respond to the requests you want them to.

In a typical organisation, for example, you want machines inside your network, such as your laptop to be able to resolve anything, and machine outside your network to only be able to resolve your public facing services, such as your web server and inbound mail. Of course, your organisation might not be typical.

To identify if your DNS servers are responding to requests you don't want them to, make such requests and see what happens! Using a machine outside your network, point a copy of dig at your resolvers, and try querying things.

To secure your DNS servers, consult the documentation for your particular brand of DNS server, and configure them to do what you want.


When choosing a numeric PIN, does it help or hurt to make each digit unique? Imagine a typical 4-digit PIN scheme containing the digits [0-9]. If I choose my PIN at random, I will get one out of 10 * 10 * 10 * 10 = 10,000 codes. Based on my own experience, more than half of the time a random sequence of four digits will contain some property or pattern that significantly lowers its entropy: single digit used in more than one position, ascending/descending pattern, etc. (Yes, yes, a 4-digit PIN only has something like 13 bits of entropy max to begin with, but some random codes are even more awful.)

If I were abide by a rule where I only use a PIN that has a unique digit in each position, I believe the number of codes available to me becomes 10 * 9 * 8 * 7 = 5,040 (somebody please correct me if I got that wrong). I have almost halved my key space, but I have also eliminated many of the lower-entropy codes from consideration.

At the end of the day, did I help or hurt myself by doing that?

EDIT: Wow, lots of great responses in here. As a point of clarification, I was originally thinking less in terms of an ATM/bank PIN (which likely has an aggressive lockout policy after a number of incorrect guesses) and more in terms of other "unsupervised" PIN-coded devices: programmable door locks, alarm system panels, garage door keypads, etc.

The thing is, with a 4 digit pin, entropy isn't really important.  What's important it the lockout and the psychology of the attacker.

The keyspace is so small that any automated attack (without lockout) would exhaust it almost instantly.

What you're worried about is an attacker guessing the pin before the account locks.  So assuming a sane lockout (say 3-5 incorrect attempts), you want your PIN to be outside the 3-5 most likely to be chosen PINs.

Personally I'd avoid any 4 digit repeating sequence and anything starting 19XX which would be a year of birth.

Now smart alecs will say "ahh but if you do that the attackers will know not to try those", but that only applies if a) the majority of the user population follow that advice (hint, they probably won't) and b) the attackers know that the user population has followed that advice.

Some great analysis of this (link courtesy of @codesincahaos)

Edit 2 - For a far more mathematical take on this I'd recommend reading @diagprov's answer


Non-deniability of WhatsApp message A is claiming that B has sent him a certain WhatsApp message. And if this incident is proven to be true, this will mean social and legal harm for B.

But as a matter of fact, B has not really sent the message.

What is the best way for B to deny that he has not sent the message?

WhatsApp uses Signal protocol which is by design offers plausible deniability in pairwise encrypted messaging. In pairwise messaging, every message is sent with HMAC-SHA256 to verify the integrity of the cipher text. HMAC uses a shared secret known to both sender and receiver.

Quoting from an answer on Difference between non-repudiation and plausible deniability

  A recepient can prove the authenticity of the message that it is indeed sent by you. If it's not him who wrote the message then it must be you who wrote it. In either manner, both the sender and the recipient can verify who sent the message. But neither of them can prove authorship of the message to others. A recepient can easily forge HMAC with a valid key to make it look like sender has sent this. He can also give away the shared secret to a 3rd party to forge HMACs in future messages.

Also, once a message is delivered, the key is deleted so there is no way to prove authorship.

In WhatsApp, you don't even have to forge HMACs. All sent & received messages are stored in Sqlite database file msgstore.db in unencrypted form in the internal storage (/data/data/com.whatsapp/files). A recepient can edit this file and modify any message that are sent by you to frame you for anything.

Even if Alice claims that Bob has sent her a message , she can't prove this to anyone. Bob can deny sending of any message sent by him.

Plausible deniability doesn't hold up in WhatsApp group messaging. In group messaging, a sender signs the message with its private Signature key so they cannot be denied and that can be used by the law.

In a legal context, plaintext messages are almost always considered proof anyways regardless of whether the underlying protocol is deniable or not. So it also depends how judicial system in your country treats plaintext messages.


Is there a cryptographic disadvantage to applying bcrypt to an already hashed password I originally asked this on stackoverflow, but due to lack of traction and a recommendation by a user there I have asked it here too.

Imagine a scenario where a client application is sending a password to a backend server so that the server can validate that the user entered the correct password when being compared to a stored variation of the password.

The transport mechanism is HTTPS with the server providing HSTS & HPKP to the user agent and strong cryptographic ciphers being preferred by the server scoring A+ on SSL labs test. None the less, we may wish to avoid sending the original user provided password to the server from the user agent. Instead perhaps we'd send a hash after a number of rounds of SHA-256 on the client.

On the server-side, for the storage of passwords we are using bcrypt with a large number of rounds.

From a cryptographic point of view, is there any disadvantage to performing bcrypt on the already sha-256 hashed value as opposed to directly on the plain text password? Does the fixed length nature of the input text when using hashes somehow undermine the strengths of the algorithm.

I'm not asking about performance such as the memory, CPU, storage requirements or wall clock time required to calculate, store, sent or compare values. I'm purely interested in whether applying a hash prior to applying bcrypt could weaken the strength of bcrypt in the case of a disclosure of the full list of stored values.

I've read posts this (which I find interesting and useful) but I'm not specifically asking whether it's a good idea to hash on the client side - I'm more interested in whether doing so could somehow weaken the password storage system with bcrypt given that an attacker armed with this knowledge would know that all values stored are a derivative of a fixed set length of inputs consisting of a much smaller range of possible characters (SHA-256)

Well, in theory explicitly using SHA256 outputs as input limits the amount of possible inputs, but the huge(!) number of SHA256 outputs makes this a negligible factor. Knowing this provides no real advantage (as far as we know today), as the hash output is pretty much pseudo-random. There shouldn't be much difference between all possible SHA256 outputs and 2256 random strings being fed into the function. You can't really derive a pattern from the outputs (if you could, the hash function is bad). I can't see any major implications from a cryptographic perspective.

A comment on your scenario, or why client-side hashing imho is not an improvement over sending plain text:

Using client-side hashing prevents an attacker from getting a clear-text password, IF (huge if, as you described a lot of high security standards) they can comprimise the connection SOMEWHERE. However, hashing the password before sending it, effectivly makes the hash the new password, as your server doesn't care whether or not the provided password is a hash or "topSecretK3y".

If an attacker gets this hash, its value is just a high as the original password, as he can now impersonate the victim.

P.S.: The only "drawback" is that the attacker cannot use the username/password for other websites, so you at least prevent a "password reuse attack" on other websites.


Possible security measures to put into place before allowing screen sharing I have someone who is having their non profit small company receive a financial audit. They are prepared for it but the financial auditors have asked to also do part of it remotely and would like to use screen sharing. They can say no, however, they feel if they say no, lol, then they will think they have something to hide, which they do not.

However, they don't like the idea of just allowing access without putting some security measure into place. I am a database person. I do not know how to advise him. I would welcome any advice. I was considering having him use encryption on files that do not have to be accessed, but that might not look good. And I am not sure if there is a way of tracking what they will be doing because I don't know the software they will be using.

For best security, you can use a screen sharing program that does not give the auditor control over mouse and keyboard. You can talk with them over the phone/VoIP/video chat and have them instruct your staff on what to do. Make sure the staff is properly briefed to know what can be disclosed to the auditor and what requires further authorizations (e.g. data that contains personally identifiable information).

Some video chat software has screen sharing component, e.g. Google Hangout, Skype.


RSA private/public keys Is it possible to recover a private key, given a public key and a substring/a part of the corresponding private key?

Yes, but it depends on how much of the private key you have.

RSA can always be brute-forced if you know the public key; it is protected by the sheer length of time that it will take to try out all possible factors.
If you have part of the private key, this means you can rule out a number of candidates - those that don't contain this part of the private key.
How much of an advantage this is, depends on how big the public/private key pair is, and how much of the private key you have.


Configuring Argon2id for Multiple Threads We're using argon2-jvm to use Argon2id on our Java TCP Server.

Because its argon2id instance is thread-safe, we plan to only create a single instance for the lifetime of our app and have each request handler call it whenever necessary (e.g. for new registrations and user log-ins).

We've fine-tuned our single argon2id instance so hashing and verifying passwords both take roughly 1 second on a single thread using the approach from this answer:

Use the max number of threads we can use (no. of CPUs x 2 in our case).
Use the max amount of memory we can use.
Tweak the number of iterations so it does not exceed our target max time (1 second in our case).

However, when the number of threads (TCP requests) accessing our argon2id instance increases (e.g. there are multiple users registering and logging in), its execution time increases as well.

Our plan now is to reconfigure our argon2id instance such that it still takes roughly 1 second to hash and verify passwords, but instead of doing so on just 1 thread, we'll be doing it on our expected max number of concurrent registrations and log-ins at any given time (e.g. 500 TCP requests).

Our concern is that, if we do so, then our hashes might not be secure enough because each request won't be getting as much processing as it should (e.g. a hash that takes about 1 second on max capacity might take only 0.25 seconds when it's the only request being made).

We feel that configuring Argon2id for max capacity is going to undershoot a secure configuration for each individual request. Is this how it's supposed to be done? Or should we stick with our configuration that takes 1 second on single threads but takes longer on multiple ones (we fear this might take too long for too many requests)?

UPDATE: I also asked the Crypto subreddit for their thoughts here.

There is no perfect solution. There is always a trade off between security, price and user experience. If you want to get both higher security and acceptable response times, consider using more hardware resources (higher price).

First estimate the risks to decide what security level you actually need. What are exactly the threats? What benefits can an attacker get in case of successful brute-forcing of single password? What will it costs for the attacker to brute-force a single password? Are the possible benefits and the costs commensurate? Does it make sense for the hacker at all? What can be costs to you and to your users to provide particular level of security? E.g. if you reduce the number of requests per server/container from 500 to 100 (to enable more hashing iterations) and increase the number of servers/containers x5, will be the price x5 acceptable to you?

Also we should distinguish two basic use cases.

There is a single user. For instance, a user on a laptop uses hash (derivated password) as a master password in password manager, or to encrypt/decrypt a drive.
Then it makes sense for a single hash to use as much resources as possible.
There are multiple simultaneous requests, for instance in some web application. If some requests require too much resources, other requests (normal requests that don't use password) will notice degraded performance.

The number of threads: The main purpose of this parameter is to load memory bus as much as possible. But normal CPUs have only 2 memory channels, where as many graphic cards have 6 or 8. Thus, exhausting your server you don't exhaust the resources of the attacker. Means, it does not necessarily increases your security. That's why I'd suggest to use 1 thread.

Memory: Your application is probably performing a lot of other logic besides hashing, like evaluating permissions, calculating some business logic, searching data for particular complex criteria, creating reports, etc. How much memory need such requests? How much memory can hashing use so that the performance of the main functionality remains acceptable? May be after analysis you will conclude that you can use for hashing not more than 5% of the available memory. Just model and calculate.

The number of iterations: Then tune up the number of iterations to get the acceptable response time.

Then check your assumptions on the real environment with real users. If you see that performance is not sufficient, you can still tune them. After password validation against the old hash succeeded, you can rehash the password with new (optimized) parameters and save to database.


Potential UEFI malware from Virus Total .rom scan I dumped my firmware on my Macbook with Darwin Dumper and uploaded the .rom file to Virus Total and it showed a huge amount of bad PE32 images (File detail tab), all of which seem to be detected by Cylance/Trapmine/Cybereason as Unsafe/suspicious.low.ml.score/malicious.random 6 char-long string respectively.

The weirdest thing is that 3 days ago a file with identical findings was uploaded there. Same Macbook model, ROM, EFI version, ROM Bios files names and warnings.

Can someone explain to me what do these findings even mean? Should I never trust this computer again? I'm also really worried about the identical file a few days ago, aren't firmware dumps unique for each system? Or same model machines have same firmware dumps i.e. all MB Air Mid-2012 will have the same dump?

... aren't firmware dumps unique for each system?

System firmware is the software specific to the hardware - with the same hardware you can expect the same firmware and even with different hardware same firmware might be used since hardware is often similar or only part of the firmware is used with the installed hardware. This is not much different from other software, i.e. MS Office is the same binary for thousands of systems.

  it showed a huge amount of bad PE32 images

PE32 are perfectly normal on UEFI. From https://wiki.osdev.org/UEFI:

  UEFI executables are regular PE32 / PE32+ (Windows x32 / x64) images, with a specific subsystem. Every UEFI application is basically a windows EXE (or DLL) without symbol tables.

As for these images being bad:

  all of which seem to be detected by Cylance/Trapmine/Cybereason as Unsafe/suspicious.low.ml.score/malicious.random 6 char-long string respectively.

These seem to be only heuristics applied here, not pattern of known malware. With heuristics you usually get a high false positive rate (detecting something which is not malicious as malicious) if you also want to get a high true positive rate (don't miss any potential malicious things).  My guess is that these are simply false positives given that only a few engines find this.


Allow setting both server URL and public key - security hole? We have a licensing system where our software, a commercial product we sell to people, contacts our licensing server when starting to get an OK to run.

It contacts our licensing URL and passes up an XML file signed with our public key. We verify the signing with our private key, build an XML file to send back, and sign it with our private key. The app then uses the public key to verify that it cam from us and acts on the response.

We're looking at allowing the URL and public key to be overridden with values set in the app's config. Overriding the URL would be used for letting customers test our new license server. Overriding the public key is to handle the case where our private key becomes known and we have to change it.

However, it strikes me that someone could override both to have it point to their server using their public key and they've now given everyone the ability to bypass our check.

Is this a hole in the system? And if so, is it a bad idea to allow either to be overridden? If we can safely override either one, but just one, I think the public key is the one to allow setting in the config file.

Or is there another way to go about all this?

Short answer: Yes, if someone builds their own license server and override the public key, it sounds like they should be able to use your software without paying for a license. They don't even need the URL setting for that.

The somewhat longer answer:

If I understand correctly, the client validates the signature against a public key which is shipped in the software (and subsequently allowed to be overridden). It sounds like the software has some isAnswerSignatureCorrect() method, which could be easily altered to always return true. This is what the early days of software cracking was all about.

One can also run a local webserver, redirect the license server host to localhost and crack the software, you wouldn't even need to override the URL in the config.

What I'm trying to say here: if your audience is willing to go so far as building their own license server that would return the correct XML structure to crack their license, then the current method you are using is not going to hold up very long.

  Overriding the public key is to handle the case where our private key becomes known and we have to change it.

If you fear of that happening, you should think about addressing that first. Store your key in a HSM, have it sign the response. If a 'real' HSM is too expensive, take a look at Yubico products.

If you fear losing access to the private key, consider generating a second key and ship the public key of both.

  Overriding the URL would be used for letting customers test our new license server.

Consider shipping the software with a hardcoded list of allowed servers. Or add a route/header/urlparam to the request of the current license server host to allow the request to be handled by a new system without having to change hosts.

You could use public key pinning to make sure the application only communicates with a server that serves a certificate owned by your organisation.


Techniques to detect & mitigate Crypto-ransomware? Crypto ransomware attacks are the latest concerns for our organization, we need to verify if we are adequately protected from them & if affected, what are the generic mitigation measure?

How do we proactively address these concerns?

Backups, backups, backups.

Have a good backup and restore strategy. You should be able to restore any server, network fileshare or desktop client to exactly the state it had yesterday, last week or last month (adjust these time increments according to your business needs). When you notice a malware infection, just nuke the affected system and restore it from backup.

Backups should be on a physically separated system. Backups should be pull, not push, i.e. the backup system should have permission to read from the backed up system, but the backed up system should not have permission to write to the backup system. This ensures that a ransomware doesn't overwrite the backups.

Also, test your recovery strategy regularly. I've heard too many horror stories from organizations which thought they had backups, but when the day came where they actually needed them they found out that there was an error in their backup routine for years and they couldn't recover anything.

To prevent the hassle from being necessary too often, you should also improve the security of your workstations:

Give the user accounts on your workstations limited privileges. They should only be able to run those programs required for their work.
Do not give users the privileges to install software. Have the IT department install software remotely when it's required.
Also update all software remotely as soon as there is an update available.
Have a malware scanner on all workstations.
Also run a malware scanner on all email you receive.
Having your workstations browse the Internet through a proxy server also allows you to implement additional filtering on that proxy.

But all of that is really just auxillary to a proper backup and restore strategy which is always your final safety net when everything else fails.

Detailed instructions for how to implement each of these measures would be far too long and detailed to describe here, especially because the most appropriate solution also depends heavily on your IT infrastructure and business needs. But it should give you a place to start.


What are some common security problems for companies offering internet to guests? What are some common problems for companies who offer internet access to "guests" (people employed by a different company) on their premises?

My guess would be easy to use downloads like from bittorrent, if that isn't filtered by the firewall.

What are some other things a network administrator has to keep in check?

If the network is in a different VLAN and router/switch has a secure password, you have no worries.

Don't mind if bittorrent port is open. First, firewall must worry about others things, if you close all ports, this is a limiting freedom to use this net, perhaps someone is using this port for a VPN connection. I think the worst problem  is that if you do not use a key to cipher channel, all messages could send in plaintext.


Addressing unsubscribe link leakage when an email is forwarded Since newsletters are often forwarded (and in fact successful ones encourage it!), what's the conventional wisdom on the security of unsubscribe links?
It's common practice to provide an unsubscribe link at the bottom of every newsletter or newsletter-like email sent to consenting customers, along with a List-Unsubscribe header. Unsubscribe links should include a cryptographically-secure token indicating which subscriber to unsubscribe.
The link often unsubscribes the subscriber immediately (instead of asking confirmation, either through a dialogue or sending an email with a confirmation link), and will often provide a follow-up dialogue allowing the subscriber to unsubscribe from additional newsletters they're also subscribed to from the same website, or resubscribe if unsubscribing was an accident.
So what is the convention when it comes to unsubscribe links?
Is it just user-beware: That if the user has forwarded the email, they're accepting the risk of a recipient unsubscribing them from that and any other newsletters? Should unsubscribe events trigger a notification email? Or is there a special unforwardable element that email clients remove from emails when forwarding them?
Overall, this is a relatively trivial security vulnerability, but I am wondering if this has been considered much before and, if so, what convention dictates. (The problem is briefly referred to in this question and answer and, while I agree that the problem is trivial, I'm still interested if anyone has developed a solution.)

Many mailers use the mailto trick where one needs to send an email with "Unsubscribe" in the subject to unsubscribe.

Create a mailto link in your newsletter. Perhaps add a body with some text telling the user that sending this email will unsubscribe them from the newsletter.

Unsubscribe

When the user clicks the link, their mail client should pop up a new email with the To and Subject pre-filled and ready to send the "unsubscribe" email.

When you receive the email on your server, extract the From field to find who to unsubscribe and if the Subject is "unsubscribe", then unsubscribe them. Of course now you need to deal email forging, if that is something worth tackling.

Additional information: If you want to go the standard way, RFC 2369 explains the commands for mailing lists. (EDIT: As clarified by @AdamKatz RFC 2369 is largely obsoleted these days. Check RFC 8058 for the latest functionality of email headers).


Why is linux filesystem considered DAC and not MAC Citing wikipedia's MAC article:

  With mandatory access control, this security policy is centrally
  controlled by a security policy administrator; users do not have the
  ability to override the policy and, for example, grant access to files
  that would otherwise be restricted. By contrast, discretionary access
  control (DAC), which also governs the ability of subjects to access
  objects, allows users the ability to make policy decisions and/or
  assign security attributes. (The traditional Unix system of users,
  groups, and read-write-execute permissions is an example of DAC.)
  MAC-enabled systems allow policy administrators to implement
  organization-wide security policies. Under MAC (and unlike DAC), users
  cannot override or modify this policy, either accidentally or
  intentionally. This allows security administrators to define a central
  policy that is guaranteed (in principle) to be enforced for all users.

From what I've read, with MAC, the system defines security levels and with DAC, each user is responsible for assigning permissions to access its files based on user identity and not on security level.

In Unix, you cannot assign access to a specific user to a file based on its identity (considering only the rwx permissions with groups, and not ACL). You can't even change the file ownership to another user without elevated permissions. Besides, even if you could, the access is evaluated based on your "ownership" or "membership" (owner, group or other) and not on each user's identity. This also resembles more of a MAC model than DAC.

So why is linux filesystem permissions modele considered a DAC model?

I don't think the granularity of permissions that can be achieved is relevant here. It doesn't matter if permission can be assigned to specific users, it matters which users can change permissions. Perhaps the DAC article is more clear about this:

  In computer security, discretionary access control (DAC) is a type of
  access control defined by the Trusted Computer System Evaluation
  Criteria[1] "as a means of restricting access to objects based on the
  identity of subjects and/or groups to which they belong. The controls
  are discretionary in the sense that a subject with a certain access
  permission is capable of passing that permission (perhaps indirectly)
  on to any other subject (unless restrained by mandatory access
  control)".

(emphasis mine)

The key difference between MAC and DAC is that with DAC someone who has certain permissions to a file is able to alter that file's permissions.

  The term DAC is commonly used in contexts that assume that every
  object has an owner that controls the permissions to access the
  object, probably because many systems do implement DAC using the
  concept of an owner. But the TCSEC definition does not say anything
  about owners, so technically an access control system doesn't have to
  have a concept of owner to meet the TCSEC definition of DAC.

  Users (owners) have under this DAC implementation the ability to make
  policy decisions and/or assign security attributes. A straightforward
  example is the Unix file mode which represent write, read, and execute
  in each of the 3 bits for each of User, Group and Others. (It is
  prepended by another bit that indicates additional characteristics).


Can a Trusted Platform Module be used as a Trojan Horse? Does it matter where I buy my TPM from? What are the downsides of buying a $15TPM over Ebay? Can a TPM be a Trojan horse that compromises my security?

The TPM is a passive device. It will answer to your commands but it will not act on its own - at least if it is compliant to the specification (which obviously does not apply to malicious ones).

The TPM is connected via LPC or SPI. It cannot access your system memory per se. However, as pointed out by Z.T., a malicious TPM may exploit vulnerabilities in the kernel driver and/or the software stack used for communicating with the TPM. That means, code execution by a malicious TPM is plausible. IMHO, I think if you're not a high-value target, an attack is unlikely.

Fortunately, every manufacturer ships their TPM with an Endorsement Key (EK) and an EK certificate. This is an X.509 certificate guaranteeing that your TPM device is genuine. You might want to verify it before installing it to your security-critical machine.

Assuming your TPM is not malicious, it might be less secure. Of course, there is no indication of your device's protection level besides the price, certification (e.g. Common Criteria EAL) and security issues from the past.


What is the benefit of combining different web log files with different formats? What is the benefit of combining different web log files with different formats in terms of web application security? In other words, how does combining iis log file with apache log file help in identifying attacks?

What you are describing in your question is often called Informationfusion. By being able to connect different sources of logs you can more easily increase knowledge of the context of the requests and help to determine its interpretation.

The more logs you can put in context with other logs and information the more valuable they become.

For example say your webservers are all sent to a central logging device where their format is unified. Once your logs now are unified you can quite easily use commands like:

cat weblogs.tz | cut $ip > ip.txt
netcat whois.cymru.org 43 < ip.txt > result.txt

And your now sitting on your users ASN, IP-address, Nettrange, country and other nice stuff from all your webservers. Taking this a step further you now look for suspicious clients who are visiting your servers in patterns that is not normal, maybe looking for a focused attack.

Now with all your webserver logs you could also look more into any patterns that is seen on all or just some of your webservers much easier. Like this list from zeltser.com/log-management/security-incident-log-review-checklist:

Excessive access attempts to non-existent files
Code (SQL, HTML) seen as part of the URL
Access to extensions you have not implemented
Web service stopped/started/failed messages
Access to “risky” pages that accept user input
Look at logs on all servers in the load balancer pool
Error code 200 on files that are not yours
Failed user authentication    Error code 401, 403
Invalid request   Error code 400
Internal server error   Error code 500


Which questions should be asked when evaluating the risk of a policy exception? I've been tasked with updating my department's exception request form, and I am trying to come up with YES/NO questions that can be scored to determine the risk of the request.

I am having trouble with this task, because I need questions that can apply to a wide range of Users within my organization, as some people are highly technical, while others are not tech savvy at all. Additionally, the company I work for has roughly 6k employees with many different job functions, so the questions have to be very flexible to accommodate just about any request that's submitted.

It depends on what the exception request form is for; if the policy exception relates to a service, then you'll want to ask questions about the nature of the service, e.g.:

Does the exception cover any systems which store Confidential or higher data assets?
Does the service being excepted integrate with any other services?
Is this exception covering a service which has already had a prior risk assessment? If yes, what was the risk classification given in that assessment?
Does your department interact with Confidential or Restricted assets?

Generally speaking, you're going to need more than Yes/No in most cases, imo. Just like any initial scoping questionnaire, this would probably only let you pick out very obviously-risky requests for triage.

A requestor's assessment can only elevate risk, not lower it. :P


I think my server is under attack, what can I do to stop it? Possible Duplicate:
  Invalid users trying to log in to my server

I have a small ssh server mostly used for file sharing. A couple of other people and I use it and there are only 3 users. Recently I checked the auth.log file and there was a ridiculous amount of logins from a set of hosts with different usernames. I think I'm being hacked by something like hydra and I'm not sure what to do. I put a slice of the log file on pastebin:  http://pastebin.com/Hgazhabu

I took some info out of the file for securities sake but everything you need to see is there. None of these usernames ring a bell nor does the ip.

I don't think your server is being attacked very effectively, if it's the usual "guess root account password" moronic attack.  That attack just won't work if you have sshd configured at all securely (with PermitRootLogin no).

If you're comfortable with C-language coding, you can make a "tarpit" out of sshd by following these instructions.  The last time I did that, I set up my SSH server to delay for 7 seconds on an incorrect password.  I didn't do exactly as the instructions said, but it was pretty close.  Anyway, on a bad password, sshd sleeps for some seconds, which really puts a dent in the cycles those password guessers can sap, as they send requests sequentially, and single-threaded.

If we all set up our SSH servers this way, SSH password guessing will go the way of the dinosaur.


Can I HMAC my plaintext for use as a NACL SecretBox nonce? I'm writing an application that needs to deterministically encrypt some data (where two equal ciphertexts will produce two equal plaintexts; this is acceptable and in fact desirable for this application), and I'd like to stay as far away from low-level crypto stuff as possible, as such I'd like to use nacl's SecretBox. The docs are very clear that the nonce parameter should never be reused.
Intuitively it makes sense to me that if I do reuse a nonce, but only ever for a given key/plaintext pair, then no information is revealed (other than that the plaintexts are equal, which in this case is desirable), since the attacker already has that exact information on hand. And at 24 bytes, it's considered safe to use random nonces.
So, I'd like to generate my nonce by taking an HMAC of the plaintext using the SecretBox key. My understanding is that an HMAC doesn't reveal any information about the plaintext or the key, and produces cryptographically-secure random output, and thus could be safely stored in plaintext for later use unsealing the SecretBox.
git-crypt (which has a fairly similar use case to my application) does something similar, but using AES in CTR mode, which leads me to believe this approach is likely sound, and that if I'm mistaken, it's due to SecretBox particularities and not the overall concept.
This seems straightforward to me, but I know cryptography can be anything but intuitive, so I'd like to check my understanding. Am I correct in assuming I'm safe generating my SecretBox nonces from an HMAC of the plaintext using the SecretBox key?

It is one of the options to choose a nonce. Using all of the messages than hash it ( or HMAC that will require a key). Note that in this case the same message will have the same nonce and therefore the observer will notice that.
Keep in mind that it will still have collisions, too, but those are not likely to occur. If you use SHA256 (or HMAC-SHA256) you need to trim the output to 24 bytes since the nonce size is 24 bytes. If we assume the output is evenly distributed than you will hit the same nonce in approximately O(2^96) messages with 50% probability.
Using all of the message is similar to SIV mode (SIV stands for “Synthetic IV”). In the future we will see more about the AES-GCM-SIV. SIV mode actually a nonce misuse-resistant authenticated encryption.
Another bad side of using all of the message is the performance. One has to read all of the message than encrypt. In other words, there is a double pass over the message. This is considerable especially the messages are big.
There are other options;

Random nonce: This require a good random number generator and there may not be possible for every place. So we dismiss this case. Note that the 24-byte random have negligible chance of colliding.

Use counter or LFSR and This is advised in NIST Special Publication 800-38D. This will make sure that a nonce is never occurs with the same key again. For each encryption increment the nonce ( or advance the LFSR). There is one problematic case for this once. During the system failures the current stage of the counter/LFSR may not be stored properly and this can cause the nonce usage. A mitigate is simply negotiate a new key.
This is also has a drawback; it can giving away
traffic information and that is costly for an attacker to collect this information.

Combining the random and counter/LFSR: if we split the nonce like 12-12 bytes and select the first 12 byte by random and use 12 bytes with counter/LFSR than we can also mitigate the system failure without changing the key. This still require a good random number generator. In this way, one can use the same key for 2^96 times.

If the performance is not issue you can use hashing the message while keeping in mind that the same message will have the same nonce. This is more common than it seem, considering forwarding a picture to the different people.
If the performance is the issue, the combining mode will be the choice.


Why can't SHA256 be decrypted? From many forums I saw that the SHA256 data cannot be  decrypted? If that's really true then hows is the data verified?
Whats the use of just encrypting the data?
The same question goes for the digital signatures (which I believe is the hashed value and private key)?

First, there is a difference between hashing and encryption. SHA256 is a hashing function, not an encryption function.

Secondly, since SHA256 is not an encryption function, it cannot be decrypted. What you mean is probably reversing it. In that case, SHA256 cannot be reversed because it's a one-way function. Reversing it would cause a preimage attack, which defeats its design goal.

Thirdly, SHA256 verification works by computing it again and comparing the result with the result at hand. If both results match, then the verification is successful. The theoretical background is that it's difficult to find another input which gives the same hash result. Violation of this creates a second-preimage attack, which defeats its design goal.

Finally, digital signatures are not simply hash and key combinations. But a hash function may improve its security.


Is there a secure way to transfer data outside the Internet? Since, recently, it has been proven that transferring data through the usb port is fundamentally flawed, I'm wondering if there are 100% secure ways to transfer data without using the Internet.

Suppose Alan has a computer system that has been offline for all of it's life. Alan wants to import some data from Bob. Can Alan do this and remain disconnected from the outside world?

My thoughts were, either Alan has to have complete control over the data being transferred (i.e. Alan knows 100% what he is importing), or Alan must know exactly (and I mean it) how data is being handled by his computer system. That is because, Alan might already have malware installed on his computer system, and this malware might use pieces of data from the data being transferred that might provide the communication between Alan's computer system and the outside world without actually installing any malware in the process of the transfer.

Edit:

Instead of "Alan wants to import some data from Bob", I should have written that Alan and Bob want to communicate bidirectionally while neither of them would be connected to the Internet during their communication.

When I wrote "security", I meant securing that Alan does not leak any data other than the data he intends to send. So, even if the data gets modified when it gets to Bob, and as long as the bits of data that were modified are not copied from Alan's system, it would qualify as 100% secure, for this type of security. Also, Bob is a regular user of the Internet for life with the possibility of going offline for some period of time (i.e. during the data transfer between the two).

When I wrote "Alan has to have complete control over the data being transferred", I meant that Alan has to have a way of checking bit by bit the information that is in transit, and in some way understand it precisely.

Just to be more explicit, Bob can have malware on his computer as well.

It really depends upon the specific threats you may be facing, the direction of your data transfers, etc.

USB specific dangers

You mention the dangers of USB. The main one is indeed related to its firmware opening the possibility of a BadUSB type attack. When you need to transfer data in both directions, you may therefore prefer to use SD-Cards which are not sensitive to such threats (if you use an external USB SD-Card reader, it should be safe but dedicate it to a single computer, don't share it!).

I insist here that I'm mentioning SD-Cards as a viable solution against USB firmware attacks only. In such attacks, a USB flash drive firmware may be corrupted in order to simulate rogue devices (fake keyboard, network card, etc.), such attacks are not possible with SD-Cards. I think this is the reason why we see Edward Snowden relying on SD-Cards in Laura Poitras' Citizenfour film when exchanging files between his own computer and the reporter's ones.

SD-Cards are also equipped with a read-only switch. While such switches are very convenient to prevent accidental modification of the card's content, they cannot be relied upon to prevent malicious modifications since read-only access is not enforced by the card itself but delegated to the computer's operating system.

Enforce a one-way communication

You talk about a possible leak of information by some malware on Alan's computer storing data in some hidden channel. If your transfers are mostly in one direction only and this is your main threat, then I suggest you use read-only media like CDs or DVDs. I don't know if there are still CD/DVD readers on the market, it would be the best since it would physically remove all possibility for Alan's PC to store any data on them, but even without that it would be by far harder to store any data discretely on such disk.

With some digging, you may also find some other alternatives, for instance in the thread how to protect my USB stick from Viruses you will see a discussion pertaining to USB sticks containing a write blocking switch (which works in a more secure way than the SD-Card's equivalent), the use of write blockers which are equipment normally designed for forensic purposes, etc.

Long distance communication

Implemented as-is, the solutions provided above suppose that Alan and Bob are in direct contact, which may not always be true. However, data transfers outside of any computer networks remains possible even on long distance, mostly by using usual postal mails, aka snail mail.

This method may be wrongly perceived as insecure by some people, while when used correctly it can actually present a very high security level. Such method is used by the industry when it is required to move a very large amount of data securely. Amazon provides his Amazon snowball service for such operation, Wikipedia's page about sneakernet also lists some other real-life usage examples, including funny experiments inspired from an April Fool's day RFC using carrier pigeon to carry the storage medium.

In our current scenario, Alan and Bob will need to take a few precautions to ensure everything goes fine:

Alice and Bob will need to exchange their public keys. This may sound simple, but in the concrete world Alan and Bob may have no possibility to meet even once, may not know each other and may have no common trusted third party to vouch for each other's identity or provide escrow service. However, the whole security of this system relies on the fact that this operation must be done successfully. Fortunately, asymmetric encryption greatly helps, since the leak of these keys will have no deep impact, but it will be of no help against an impersonation or tampering occurring at this step.
The chosen data exchange medium may have some importance since each may present different characteristics:

Firmware based storage devices are the most frequent nowadays, ranging from the hard disks with higher data volume to micro SD cards which can be very easily concealed. One may prefer to buy it from some physical store to avoid any initial tampering, but as we will see later the device will in all case be not trustable anymore once the first shipment occurred.
Non-firmware based device present obviously no firmware related issue, but depending on the exact needs of Alan and Bob they may present other issues in particular pertaining to anonymity: burned disks and printed paper for instance may contain unique identifiers allowing to link them to their author (such identifier does not allow the author location though, but once his equipment has been seized they can be used to prove that this equipment produced them).

Of course the data will need to be properly encrypted and signed before being stored on the medium. I would tend to prefer an encrypted file which can be more easily manipulated than an using directly an encrypted partition on the medium.
I strongly suggest for the data to be properly backed up before being sent. While such transfer is secure in the way that a potential opponent will not be able to access or tamper with the data even if he manages to intercept it, the data may still get lost or disappear (it can be the result of either a voluntary or involuntary action: it happens that parcels get lost or seized without any intervention from Big Brother, Murphy is very good at that too!).
Methods to obfuscate the actual sender and recipient (from PO boxes to more advanced stuff), when combined with concealment of the storage device, can help to avoid interception.
At least on the recipient side, I strongly advise to not connect the received storage device directly to the main computer, but instead:

Connect the received media to a specially hardened minimal system (aka a sheep dip, the host itself may have no hard-disk and boot from a LiveCD) where you will be able to quickly inspect media content and the encrypted file (do not decrypt it on this host!),
You may possibly want to copy the encrypted file to a more trusted support (here one case where using an encrypted file instead of an encrypted partition can be useful). Moving the encrypted file to another support may be especially useful if using a firmware base storage device since, once it went through the postal service, you cannot guaranty the firmware integrity anymore (while the encrypted data is signed, there is no signature you can check for the rest of the storage device).
Then you can connect this most trusted support on your main air gaped computer where you will be able to safely decrypt it, making this step the end of the story :).


Is it possible to mac-spoof Xfinity Wireless? Background

Comcast/Xfinity operates various wireless hotspots across the US, accessed via the SSID xfinitywifi through the many wireless access points shown on https://hotspots.wifi.xfinity.com/

xfinitywifi hotspots are all open/unsecured, and, to use such a hotspot, an Xfinity subscriber simply connects to the xfinitywifi SSID. Only Xfinity subscribers are allowed to use a hotspot, and if an unrecognized device connects to xfinitywifi, the user of that device will be redirected to an Xfinity Wifi login page, where they enter their Xfinity account credentials.

If all is good, Xfinity will simply store the MAC address of that device, and associate it with that subscriber's account. All of this happens seamlessly and invisibly to the user. And anyone using that device will never have to go through a login screen for xfinitywifi ever again! (unless that subscriber manually goes and removes that device via https://www.xfinity.com/support/articles/manage-wifi-devices-my-account, a page most Xfinity users likely know nothing about!)

Question

Does Xfinity recognize "allowed xfinitywifi devices" solely via their MAC addresses? If so, then what prevents someone from creating a malicious access point broadcasting SSID xfinitywifi, but secretly pointing to the legitimate xfinitywifi SSID, from sniffing (while sending over the unmodified) subscribers' MAC addresses? (i.e., to obtain mac address(es) for free internet service or for masking illegal internet activity)

Edit #1: One might say, "what about the volume of non-subscribers connecting their devices just hoping to get free wifi?" Well, you can probably find out which MAC addresses are registered or not by monitoring which traffic goes to the users' intended destinations, and which MAC addresses just end up sent over back to the Xfinity website (presumably for login purposes). The idea is just to steal MAC addresses, not login credentials, since apparently the right MAC address is all that's needed for xfinitywifi internet service anyway.
Edit #2: Xfinity might automatically de-register MAC addresses when it notices the same one being used from two different networks. In that case, just have the malicious access point do some MAC address translation instead. The valid users that end up repeating the Xfinity wifi login process will then have, unbeknownst to them, secretly added new MAC addresses to their list of allowed devices (under their Xfinity account/s). And now the hacker has something they can use for free internet service (or masking illegal activity spoofing as some other innocent Xfinity subscriber instead).

It looks like this is a known vulnerability, aka CVE-2017-9475.

The National Vulnerability Database currently assigns this a CVSS 3.0 score of "5.9 - Medium", but claims the "attack complexity" (AC) is "high". However, CVSS 3.0 only provides two values for AC anyway -- either low or high:

  Low (L):
  Specialized access conditions or extenuating circumstances do not exist. An attacker can expect repeatable success against the vulnerable component.

  High (H): A successful attack depends on conditions beyond the attacker's control. That is, a successful attack cannot be accomplished at will, but requires the attacker to invest in some measurable amount of effort in preparation or execution against the vulnerable component before a successful attack can be expected. For example, a successful attack may depend on an attacker overcoming any of the following conditions:
    - The attacker must conduct target-specific reconnaissance. For example, on target configuration settings, sequence numbers, shared secrets, etc.
    - The attacker must prepare the target environment to improve exploit reliability. For example, repeated exploitation to win a race condition, or overcoming advanced exploit mitigation techniques.
    - The attacker must inject herself into the logical network path between the target and the resource requested by the victim in order to read and/or modify network communications (e.g. man in the middle attack).

Also, some good recommendations (such as the use of wifi certificates) are included here as well: https://github.com/BastilleResearch/CableTap/blob/master/doc/advisories/bastille-17.public-wifi-theft-impersonation.txt


Which protocol should I use for secure message transfers between two servers? There are two servers.
I am going to transfer very secret messages from the first one to the second.

The second server (the one that receives data) doesn't have access to any other resources except the first server.

Messages are simple JSON strings whose lengths don't exceed 1024 symbols and usually are much smaller.

Which protocol should I use for very secure data transfers? Does it really matter or can I take the easy way and just use HTTPS?

PS. Data processing and storage is absolutely another story. I care only about data transfer.

TLS - for sure.
You can use client certificate and choose strong ciphers.
If servers are not limited in trafic - add some entropy data flow inside the socket.
If you wish to transfer two directions - https is not a solution. SIP. Or XMPP. Or WebSocket or any other TCP Socket implementation with TLS support.
In addition to comments:

TLS is well implemented, open source, fast and reliable transport layer protection. So, when we speak about channel encryption, it provides enough security, if to set up both sides properly: strong ciphers, avoid SHA1 and SSLv2/3 usage (Jan 2021 - TLSv1 is dead too).
It is very important not to give to potential attacker a chance to determine any significant part of message for compraison. Modern ciphers can stand against this decryption method. However, I think that it is good style if you mix some random data that can be considered pseudo entropy to the data channel.
As long as you need to communicate between two servers, let's say that data transfer model must be equal on both sides, so each part can act both as client and server, having equal data transfer abilities.
Of course, it will be TCP - needed to guarantee packet receipt. This task data takes one IP packet, so if UDP (DTLS) looses packet, even transfer fact will be lost.
XMPP or SIP: one of servers will be local for SIP or XMPP (I prefer the last) server and remote for another. So, it is additional authentication for data transfering backends. (2021 update) Websocket - nice solution too if you wish to code. Number of frameworks to implement client and server.
As for self signed certificates. If you create correct chain with Root - Intermediate and Server certificates properly signed - both servers can check their validity by adding Root and/or Intermediate certificate to trusted CA list.
Why not https? Trafic can pass operator's proxy and you will never know it. Some proxies use to bump ssl. Moreover, it is public port that for sure has risk of botnets attack. It will be single side communication, where one always is a server and another is a client, where client to server side instructions need to pass additional authentication and web oriented backend. And the last - it is not so fast, cause http is not designed for service data transfer. I would say, that https is good only for low security level data such as session validity confirmation.

I would create an XMPP bot that is reliable, has reach and flexible stanzas set for anything: presence, data transfer and even files transfer. If the system must be extremely paranoid - OTR encryption can be added.
Conclusion: For 1024 symbols messages (1 or few IP packets) TCP as transport protocol to ensure delivery (socket), TLS as transport layer security to simplify implementation, CA signed certificate to avoid MItM. Application layer - SIP / XMPP / WS


Does the md5 (or any hash for that matter) of a string include the null terminator? Does the md5 (or any hash for that matter) of a string include the null terminator in its calculations? That is does the hash of a string equal the hash of the sequence of bytes that represents the string minus the null terminator.

I think this depends more on the implementation of the hashing algorithm than their ability to hash a null-terminated string including the null-terminator itself.

A few of such occurances of hash function implementations were observed in TrouSerS (version 0.2 built on Trousers Software Stack 1.1, or earlier) used in Gentoo Linux as one of the crypto libraries in its software stack and in TrustedJava (before jTSS 0.4a), and in IBM Client Security Software, both implementations included null-terminators on password popup dialog entries (null-terminated strings including null-terminators themselves).

Similarly, you can UTF-16 encode plaintext before passing it to the hashing function, causing every other character in the input to be procesed as 0x00 or null character for non-extended characters by the function that processes input as plain ASCII. Depending on the hashing algorithm itself, its intended purpose, and the input length, this could be either beneficial (say, to password hash security, e.g. hashcat has some problems with these), or cause decreased password entropy, if that causes the hashing algorithm to ignore parts of the input (e.g. bcrypt, a cryptographic key stretching hash algorithm implementation based on Blowfish symmetric block cipher, limits plaintext to 72, 55, or 51 characters - depending on who you ask - and ignores the rest).

As for a general advice whether to include null-terminators in inputs to your hashing algorithms, I have none and you should be a bit more specific about the intended use you're hashing data for (are we talking of cryptographic hashing for password storage or HMAC here?), and will vary greatly depending on your specific needs and chosen hashing algorithm.


What is 'Modular shell disassociation from kernel' Under many difference resources (https://en.wikipedia.org/wiki/Code_injection for one), there are some great tips to defend against code injection.

However, one of those is 'Modular shell disassociation from kernel' - but after quite a bit of Googling, this term doesn't seem to be defined anywhere - but every other site seems to copy and paste it as a defence mechanism for code injection flaws.

Can someone describe what 'Modular shell disassociation from kernel' actually means?

I agree with your observations that this specific term is not well-explained and that a lot of sites seem to just parrot each other.

While i am by no means a linux dev, my best guess would be to look at the the unshare() syscall:

  unshare allows ... an ability to
  disassociate parts of the context [such as
  virtual memory and open files]

Source

  unshare can be used to implement polyinstantiated directories using
  the kernel's per-process namespace mechanism. Polyinstantiated directories,
  such as per-user and/or per-security context instance of /tmp, /var/tmp or
  per-security context instance of a user's home directory, isolate user
  processes when working with these directories. Using unshare, a PAM
  module can easily setup a private namespace for a user at login.


What precautions should I take before letting users send email through my app? I'm working on a contact management/lightweight CRM app, and I'd like to be able to allow my users to send email to their contacts through my application. Obviously this opens up a huge can of worms in terms of security, so I'd like to know what can be done to mitigate or minimise the risk to both my organisation and genuine (non-spamming) users, as well as keeping my app reputable.

The application itself will make API requests to a third-party mass SMTP provider and let them do the actual sending, rather than send it directly from our server(s).

These are some current precautions I am taking:

Users will only be allowed to send email to their contacts or accounts already on the system, no mass emailing lists of addresses only.
Emails are rate limited, each user will only be able to send n emails in a 24 hour period where n is based on their subscription plan.
Using the "on behalf of" feature for the sender address.

What I would specifically like to know is:

Some users may want to send from a no-reply or other corporate address, different from the email they use to log in. How should I best verify users own or have access to the address? I can't always use verification emails because if they want to send from an unmonitored address they obviously won't be able to check for said verification email.
Is anyone able to explain how I should make use of SPF records (or get my users to make use of them) in this instance? I have read about them but my knowledge is still shaky in this area.
Will there be any special precautions to take if we scale the app over multiple servers?

As an additional note, like the market leader Salesforce, I intend to allow my users to send an unlimited number of single (non-bulk) emails to other users, but above I am talking specifically about emails sent to non-users.

Emails are rate limited, each user will only be able to send n emails in a 24 hour period where n is based on their subscription plan.

Obvious first step, rate-limit emails per user.
Rate-limit new signups. In your case it looks like users have to pay for access, so that is an effective rate-limit. This is important if you rate-limit emails per-user. You obviously don't want a single person bypassing this by easily creating a large pool of users.

  The application itself will make API requests to a third-party mass SMTP provider and let them do the actual sending, rather than send it directly from our server(s).

Mail receivers often track sender reputation per IP address. Since you are using a third-party provider to send the emails, then it is their IP which will take the reputation hit not yours. This is important, as you don't want your all-important company Email Server to be on the same IP that sends less-vetted emails.
It may be best to throttle emails sent so you are not recognized as a DoS attacker by various mail receivers, but your provider may do this for you automatically.

  Some users may want to send from a no-reply or other corporate address, different from the email they use to log in. How should I best verify users own or have access to the address? I can't always use verification emails because if they want to send from an unmonitored address they obviously won't be able to check for said verification email.

If you cannot verify they own the email address, you must instead verify they own the domain. This is a good subject for a separate question, but in short, I would suggest you look at how SSL Certificate providers verify ownership.

Email verify to limited set of known admin account usernames. (postmaster@example.com, etc)

Alternatively, check the WHOIS and send your email verification to the Admin contact there.
DNS verify by requiring them to add a specific random TXT rule.
You could use HTML web page verify but that could potentially be disconnected from what really needs to be verified.

  Is anyone able to explain how I should make use of SPF records (or get my users to make use of them) in this instance? I have read about them but my knowledge is still shaky in this area.

SPF records are managed by the From domain holder.

If you are sending From your domain, with a Reply-To of the customer's domain, then SPF is simple to configure, but should be a separate question.
If you are sending From the customer's domain, then it is your customer's responsibility to list your sending server IPs, so that they are not accidentally adding spam points to those emails.

For customer convenience, you should probably publish an SPF rule, so that your customer can include it. This way if you make any changes, such as switching SMTP providers, then your customers will not have to update their SPF ruleset.

The SPF rule you publish can be a simple include of whatever your SMTP provider has published on their end.

  Will there be any special precautions to take if we scale the app over multiple servers?

As I said above, receivers track reputation per IP. (in your case, the SMTP provider) I would point out that your servers should be synchronized so that rate-limiting is enforced. You don't want the user connecting to a different server to be able to bypass a rate-limit error.

  As an additional note, like the market leader Salesforce, I intend to allow my users to send an unlimited number of single (non-bulk) emails to other users, but above I am talking specifically about emails sent to non-users.

You may consider sending these from yet another IP (if your SMTP provider assigns IPs to you) so they get a separated mail reputation from the bulk emails.
You should always have some rate-limit, even if it is not advertised, to prevent robotic or user-script submission.

  Users will only be allowed to send email to their contacts or accounts already on the system, no mass emailing lists of addresses only.

This is helpful from a user perspective, but I assume that technically they can add contacts to their system using a user-script, so this probably is not relevant to the determined spammer?

  Using the "on behalf of" feature for the sender address.

I'm not 100% sure how your are doing this, but it does sound like a reasonable thing to do.


Detecting OAuth malicious Implementation I am wondering how can an end-user detect a maliciously implemented OAuth whether 2-legged or 3-legged. Particularly I am interested in those cases where the consumer requester is maliciously presenting to the user a fake resource provider page to enter the credentials. Typically if the consumer is expected to forward the requester to Facebook let's say but what the consumer does it present to the user a fake Facebook page. That would allow the consumer to spoof the identity of the user in the future...

Did OAuth recommend anything with that regards?

In particular I am interested in use cases in a browser environment.

The OAuth RFC states:

  OAuth uses tokens to represent the authorization granted to the
     client by the resource owner.  Typically, token credentials are
     issued by the server at the resource owner's request, after
     authenticating the resource owner's identity (usually using a
     username and password).

  There are many ways in which a server can facilitate the provisioning
     of token credentials.  This section defines one such way, using HTTP
     redirections and the resource owner's user-agent.  This redirection-
     based authorization method includes three steps:

  The client obtains a set of temporary credentials from the server
     (in the form of an identifier and shared-secret).  The temporary
     credentials are used to identify the access request throughout
     the authorization process.
  The resource owner authorizes the server to grant the client's
     access request (identified by the temporary credentials).
  The client uses the temporary credentials to request a set of
     token credentials from the server, which will enable it to access
     the resource owner's protected resources.

So to have the authorisation, the client (the site using your data) must redirect you to the server that holds your data for signing up.

At Section 2.2 the RFC states :

  The way in which the server handles the authorization request,
     including whether it uses a secure channel such as TLS/SSL is beyond
     the scope of this specification.  However, the server MUST first
     verify the identity of the resource owner.

But definitely I (as resource owner) won't use any OAuth-orisation without checking the certificate of the site.

So for OAuth 1.0 this is not mandatory.

The OAuth 2.0 RFC is still a draft but I understand that it requires TLS

  10.9.  Endpoints Authenticity

  In order to prevent man-in-the-middle and phishing attacks, the
     authorization server MUST implement and require TLS with server
     authentication as defined by [RFC2818] for any request sent to the
     authorization and token endpoints.  The client MUST validate the
     authorization server's TLS certificate in accordance with its
     requirements for server identity authentication.

[...]

  10.11[...]
     To reduce the risk of phishing attacks, the authorization servers
     MUST utilize TLS on every endpoint used for end-user interaction

Hence the authentication relies on TLS protocol as it was discussed on the blog recently.

To summarise I would suspect any attempt to OAuth without TLS as malicious. And of course the same if the SSL certificates does not validate.