Do burned DVDs contain trackable information?

DVD-R discs include the serial number of the drive used to burn them.  There is a program called DVD Info Pro that is able to read that part of the disc and extract the drive's model and serial number.  To do so, select "Read burn info from DVD-R/RW media".

Commercially pressed discs don't seem to contain any such information.  I was unable to find any information about whether DVD*+*R discs record any serial numbers.

I don't believe any personally identifying metadata is kept when converting to video DVD formats.  Someone may however be able to tell what software was used to encode and burn it, either because it records the application ID in the DVD's media information, or just by looking at encoding methods specific to that program and it's typical settings.

There is also usually some small engraved writing at the center of the disk which can identify the manufacturer of the blanks and the batch it came from, which may or may not be enough to track down where the discs were sold.


What is the best way to generate keys in phpseclib?

See the "Generating Keys" section of the Encryption documentation.

It suggests using the following code to generate a random key:

<?php
$key = \phpSec\Crypt\Rand::bytes(32);

For the sourceforge project, it appears that if you want a password-derived key, then you can use ->setPassword() on the Crypt_AES object.  However, the only generation of random data that I could find is the generation of a random number.  That is done through the crypt_random function. I would suggest just taking the necessary functions out of the other phpSecLib.  As it is MIT-licensed, this shouldn't be a problem from a license point of view.


Maybe? shrugs

That is likely the best answer I can give. I say this because most responsible admins have taken steps to eliminate the heartbleed vulnerability from their systems.

So, for the most part if the majority of sites you visit are mainstream, then you are likely going to be fine.

However there are also those admins who have not patched...for one inexcusable reason or another. And their site continues to be vulnerable.

Now the problem is, without Chromebleed...how would you know if a new site (new to your normal list of urls) which you were visiting was vulnerable or not, before you passed it sensitive information?

Sure it may not matter if you never post anything to random websites you don't want the world knowing.

...but do you only ever just post public information to new secure sites?

Security is all about risk assessment and mitigation, so if the majority of sites on the internet that you visit are known safe, and you're careful about new sites. Then in your case, the need of the tool to detect unknown threats may not be significant enough to you to matter.

On the other hand, if you like to live a little more dangerously...maybe you read the latest hacker news on a hand full of fly by night hacker sites or perhaps you indulge in a few torrents once in a while...

Then you should likely keep using it. The nice thing here is that to continue to use this tool requires a minimal amount of effort for a maximum amount of protection against this issue.

Like I said, this is all about what you consider an acceptable level risk analysis and mitigation.

On that note, it's crazy to think there are still SSLv1 - SSLv3 sites operating on the web today. So it's not so crazy to think you may still find a site afflicted by Heartbleed.

As of 2014 approximately 18.7% of websites checked were using SSLv2, and specifically 38 sites only supported SSLv2...just wow.
TLS Survey: Jan 11 2014


DNSSEC and DNSCurve address completely different aspects of DNS security.

First of all, DNSSEC does NOT sign your queries. Rather DNSSEC allows a zone (such as a domain) to be signed by its owner, and allows a resolver (for instance Comcast's DNS servers) to verify the signature, and therefore be sure that the zone data it gets is authentic. It protects the resolver from receiving bad data, but does nothing to prevent MITM or snooping between you and the resolver.

DNSCurve, on the other hand, encrypts communications between recursive resolvers and authoritative servers and allows authoritative servers to sign their data against forgery, but does nothing to protect an end-user client from a bad recursive resolver.  OpenDNS's DNSCrypt solution is based on the same technology as DNSCurve, but protects the last-mile between a trusted 3rd party recursive resolver like OpenDNS and the end-client.

As for which is more secure, neither is. They are both secure, however the security is applied in different areas. In either case you are picking which aspect of DNS security is more important, rather than which security tool is stronger.

As for what you should do, that is something only you can decide, but do please consider the following:

You could use Comcast's DNSSEC resolvers and hope no one snoops and MITMs the connection between your machine's and Comcast's resolvers.
You could use OpenDNS's resolvers, connect to them using DNSCurve, and hope that no one feeds bad data to those resolvers, as they do not use DNSSEC. (To be fair, OpenDNS has a very good track record of preventing such attacks.)
You could run your own resolver using freely available open source software such as BIND, PowerDNS, or Unbound; enable DNSSEC on said resolver; and keep the queries on your local network—or better yet, run a resolver on each machine.  (This is the best option IMHO, as it addresses the weaknesses of both of the other two options)


From their product page, we can infer a lot about how their system works. Here are the key points:

  Can be used with Windows XP and Windows 7
  Comes with: VirtualBox 4.0.16, hardened Linux Debian 6 and SELinux and Firefox
  Browser execution takes place in separated virtual machine with own operating system
  Downloaded files are first scanned and then provided to user
  Configurable security polic for copy & paste, download, upload and printing
  Reset to certified initial snapshot upon each start of the browser
  Configuration data of the browser can be stored persistently and are retained for restart

So apparently it runs Firefox on Debian 6 Linux with SELinux inside a virtual machine running inside VirtualBox, on a host that must be Windows.

As for how secure that is, for the most part, it's the same as running a browser inside a Linux VM in VirtualBox with a snapshot you roll back every time you want to reset. Except that they are actually using a very outdated version of VirtualBox from 2012, which is probably a bad idea for lack of security updates. I get the feeling development on this product is abandoned.

While a virtual machine does add security, virtual machine breakouts do exist, and VirtualBox has be on the receiving end of such exploits before.


A couple of pointers:

Using SAMBA significantly reduces your security. for what you propose SSH would be a better fit (when utilizing Public keys)
nginx does NOT use .htaccess (and htaccess is horrible for performance and security). you should configure everything in the (virtual-) host directives. (so in the /etc/nginx/sites-available for most *NIX'es)
When utilizing SSH you could use a shell, and than GPG encryption could be utilized to protect your file (with the bonus of not having to disclose your public certificate, which could tip an attacker, before entering your system, that you are using it for encryption of a specific file)
Usability wise your solution is a lot of steps. many of which add no (additional) security at all. I would suggest you look into jails / chroot for additional levels of protection.


How does an offline Root CA sign OCSP Response?

OCSP responses may be signed not only by the CA itself, but also a designated OCSP signer. That's an X.509 certificate issued by that CA with the OCSPSigning (1.3.6.1.5.5.7.3.9) extended key usage.

For details see RFC 6960, section 4.2.2.2.


Will the recently found OpenSSL vulnerability Heartbleed affect my public site for which I obtained an SSL certificate from a CA?

There is no problem with CSR's generated with a vulnerable version of OpenSSL.

This doesn't mean your keys were not compromised via an actively running server, but it sounds like you understand that.


Checking if current user exists before executing code

I'm not sure about your application, but what you seem to be missing is that the user has some sort of control over the model (i.e: the ability to delete it).

If your application allows users to be created without any intervention/approval, anyone could create a new user (and thus, have a valid current_user), and remove all objects by just iterating through all your id values:

/url/1
/url/2
...

Again, not sure what your app does, but you may want to put something like:

if current_user
  @model = current_user.models.find(params[:id])
  if @model.destroy
    flash.alert = 'Model deleted successfully'
    redirect_to models_path
  end
end

This will only allow a user to remove his/her own objects, not every object on the system.


Is it safe to set rejectUnauthorized to false when using Heroku's Postgres database?

Heroku does not support client-side certificate validation to its Postgres databases unless you are using Private Spaces or Shield:

  Unless you're using a Private or Shield Heroku Postgres database, Heroku Postgres does not currently support verifiable certificates.

My understanding is that in this case, the best you can do is:

Your connection is encrypted and you are protected from eavesdropping
Not protected against Man-In-The-Middle (MITM) attacks

ssl: {
  sslmode: 'require',
  rejectUnauthorized: false,
}

This is the highest level without certificate validation, according to the table here:


Testing non‐browser‐based https clients for Poodle

I would start by finding out which SSL library it is using. I wouldn't be surprised if it used (maybe embedded) an old openssl version, in which case there would be a number of vulnerabilities to take into account that could be easily extracted, not just poodle.

As pointed out by  schroeder, you could launch a webserver that doesn't speak anything newer with:

openssl s_server -no_tls1 -no_tls1_1 -no_tls1_2

But it is much easier to attempt retrieving
https://sslv3.dshield.org/vulnpoodle.png which is part of the https://www.poodletest.com/ test

sslv3.dshield.org is a server which only speaks ssl3. Thus, if your tool is able to retrieve it, it supports SSL3 in the configuration you are using.


Can p2p use be traced by targeting a known individual rather than an offending IP Address?

There is no name in P2P networks. Your IP address is visible, but not your name. Of course, the name can be tracked back by asking the ISP, but this requires asking the ISP.

So the problem is: given an individual identified by name, can you find his current IP address without going through the subpoena+ISP path ? Well, it is sometimes possible. For instance, if the individual posts a message to Usenet through a client which uses the NNTP protocol, then chances are that the Usenet server will add an NNTP-Posting-Hostheader field containing his IP address -- thus his current IP address will be revealed (and published worldwide). Other common IP address leakages occur in sent email headers.

With a VPN and some care (e.g. not posting to Usenet directly, only through the VPN), an individual could keep his IP address "private", to be revealed only when legal action occurs.


One tangible example is timing attack on string comparison. It works by measuring how much it takes for the application to compare 2 strings.

The default string comparison implementations in nearly all programming languages are optimized and they work by comparing 2 strings character by character and they alert a mismatch as soon as they see a difference between the 2 characters currently being compared.

So if we have this code in our application:

def string_compare(a, b) :
    if (a == b)
        return True
    else
        return False
1: string_compare('abcdefg', 'abctyf2')
2: string_compare('abcdefg', 'abcdefb')

What happens is that (1) and (2) are going to take different amount of time to run. (1) fails faster than (2) so if we change our input (second string) one character at a time by measuring the time it takes for the function to return, we can guess the first string.

To mitigate this timing attack we have to change our code so that it takes a fixed amount of time regardless of what the inputs are:

def safe_string_compare(a, b) :
    if (sha256(a) == sha256(b))
        return True
    else
        return False
OR

def safe_string_compare(a, b) :
    if len(a) != len(b):
        return False

    result = 0
    for x, y in zip(a, b) :
        result |= x ^ y
    return result == 0

I find this reference helpful: coding rules


Why does Amazon verify a TLS certificate?

https://support.mozilla.org's certificate is signed by the Amazon Certificate Authority, Amazon Trust Services. This is widely considered a trustworthy third party for signing certificates, and your browser is apparently configured to trust certificates signed by Amazon Trust Services without prompting you.

There are many Certificate Authorities in the world, which sign certificates for individual web sites. There is no single universal authority that validates websites; each browser picks a set of CAs that they will trust by default, but you can configure trust, sometimes for the browser specifically and sometimes for your operating system as a whole. (It depends on the browser and OS in question.)

In theory, a rogue CA can issue fraudulent certificates and do things like spy on you. Any CA could do that, not just Amazon. In practice, CAs are trusted precisely because they are trustworthy. It is unlikely that they would abuse that trust, but it is not impossible. For example, when Symantec had issues with their security, browser vendors stopped trusting certificates signed by Symantec.


This is a basic and quite popular scam that uses social engineering to make gullible people believe there's something wrong with their computer in order to sell them some fake security solution and/or possibly steal data from the machine in the process.

The scammers are often based in India and use VoIP providers to call at cheap rates and appear as a local number, and for card processing they obviously use shady payment gateways that don't mind this illegal activity.

Most of the social engineering works by making the user open the event viewer and telling him that the errors in there (which are often benign and to be expected on such a complex OS like Windows with so much services running) are critical and mean that remote attackers are trying to take over the computer. They will then get the user to download a Remote Desktop server like TeamViewer (but TV has a warning specifically against these social engineering attacks so they fall back to some other, less known remote desktop solutions that have no such warnings) to take control of the computer and further show that the machine is in bad shape, sometimes by opening a command prompt and copy/pasting some command that produces lots of output with something scary appended at the end like the "tree" command with the text Warning: computer infected. Attacker's IP: 192.168.1.1 after it, which causes the window to list every single file of the system and display the text at the end as if it was part of the command's output, which unfortunately is an effective scare tactic. Once the user is convinced they make him go to their webpage to buy a solution which is often a fake security product, and assuming that's done I suppose they either just leave or install a rogue (fake antivirus). Note that most remote desktop services include a way to silently transfer files that can be used to exfiltrate confidential data from the victim's computer in addition to exfiltrating their money.

There are a lot of these scam calls posted on YouTube, you can look up "tech support scam" on there if you want. You can also play with them by setting up a virtual machine; just try to make it a bit fun (like creating actual malware, disguising it as a "passwords.txt.exe" with a text document icon and hope the idiots steal the file and run it on their computer).


Can a neural network crack hashing algorithms?

No.

Neural networks are pattern matchers. They're very good pattern matchers, but pattern matchers just the same. No more advanced than the biological brains they are intended to mimic. More thorough, more tireless, but not more sophisticated.

The patterns have to be there to be found. There has to be a bias in the data to tease out. But cryptographic hashes are explicitly and extremely carefully designed to eliminate any bias in the output. No one bit is more likely than any other, no one output is more likely to correlate to any given input. If such a correlation were possible, the hash would be considered "broken" and a new algorithm would take its place.

Flaws in hash functions have been found before, but never with the aid of a neural network. Instead it's been with the careful application of certain mathematical principles.


Is SFTP going to improve Wordpress security?

Um, I think your really confused about the technologies in use.
 you do not use FTP at all when using SFTP. Sftp is using an SSH connection between server and client and uses the sftp protocol for the file handling.
(so no ftp is being used at all).

SSH is a proven reliable and secure remote shell protocol that always multiple methodologies to not only encrypt but also to identify connections and user-sessions. You should always use a Public / Private key when using SSH for added security, but even without it SSH allready protects against MiTM and server-spoofing

(it 'knowns' the public key hash of the server after the initial connection and there for knowns when that is different and warns when that is the case).

this is all asuming you use SFTP to pull in an update.

When you push updates to your wordpress the whole security profile changes. SSH  by default stores your acces permsissions in a location athat is NOT accesable by your website (the users's home or the systtesms shadow file) Also you can setup your acces in such a way that the SFTP connection is 'jailed'.

This means that the 'shell' only has acces permissions to a very limited subset of the filesystem and to none of the systems file or tools outside what is configured.

The way you are describing 'SFTP' sounds like FTPS, or TLS+FTP. that would mean that there is a FTP deamon running on the server that also has TLS capabilities (just like a HTTP deamon would have to server HTTPS sites)

Even in that situation you could have additional security from using FTPS but it is a lot harder to configure, and has all the drawbacks of FTP.


The metadata file doesn't have any sensitive information in it. It provides information that the SP can use to trust an assertion coming from [IdP] (so no one else can claim to be [IdP]). The typical information it contains are:  SSO URL, issuer name, and the certificate containing the PKI "public" key. All of these are pretty much public anyway (as any user can see them in the SAML assertion if they capture it in the browser). With this information, the bad guy cannot really do anything.

Source link went dead.


Where does tamper data extract the password string from?

Tamperdata intercepts POST and GET traffic. If this is a POST request, then it is stored in a form as hidden attribute, or it is generated with an XHR request. Either way the client initiates the action, and tamperdata hook in on the calls.


What can an attacker do with an OpenID token

The token essentially is what gives you access for a certain amount of time. So, yes an attacker could use the token to access a system.


Symmetric or asymmetric encryption for JSON Web Token?

I would say the main advantage of option 2 is that there is no need to distribute (or update in case it gets compromised) a pre shared key. If you can somehow make sure you have a secure mechanism of transfering the pre shared key, (i.e. there is only one person you need to do this with, and you're confident in talking to them on the phone and spelling out the key -- obviously this has security risks (phone taps, key written down on paper on the other end, etc) that you need to evaluate) I would go for option 1. However if you want to build some api interface where clients can connect and start secure connections without an out-of-band key exchange, go for option 2.


Security against local attack for remote FDE decryption?

According to this helpful blog about using TPM to auto-decrypt FDE disks, a local attacker can replace initramfs (because it resides on the unencrypted boot partition) and decrypt the disk even though the key is in TPM. I think this means all methods (dracut-sshd, clevis/tang, etc) suffer the same weakness.
(Anyone care to point out which method they consider lowest risk?)
The article claims there is no fool-proof way to accomplish what is being asked by this question -- yet. It lays out a couple ideas that people are working on for future iterations of the technology.


Are automatic "out of office" email replies bad security practice?

On many email servers it is possible to confirm whether an email address exists or not depending on whether you get a bounce message back from their SMTP server.

e.g.

Return-path: <>
Envelope-to: sender@example.com
Delivery-date: Thu, 25 Oct 2012 16:42:54 -0400
Received: from mailnull by ecbiz103.example.org with local (Exim 4.77)
id 1TRUGT-0005Qd-RT
for sender@example.com; Thu, 25 Oct 2012 16:42:54 -0400
X-Failed-Recipients: recipient@example.edu
Auto-Submitted: auto-replied
From: Mail Delivery System <Mailer-Daemon@ecbiz103.example.org>
To: sender@example.com
Subject: Mail delivery failed: returning message to sender
Message-Id: <E1TRUGT-0005Qd-RT@ecbiz103.example.org>
Date: Thu, 25 Oct 2012 16:42:53 -0400

This message was created automatically by mail delivery software.
A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:

recipient@example.edu
No Such User Here

------ This is a copy of the message, including all the headers. ------
Return-path: <s...

However, existent but inactive accounts would not generate such a message.

The out of office autoreply does confirm that the email exists, and that it is in active use. As you say, depending on the contents it could leak information regarding the whereabouts of the recipient. This would be more of a concern for personal email accounts than that of a corporation because it is more likely that the user is physically not present at their home should such an email be received.

Some mail systems can be set to only reply to known addresses in the local address book with the out of office message. This prevents any malicious senders from gaining from their information gathering exercise. Also, many systems that filter email into spam folders do not send autoreplies for such messages.


Are all steganography tools alike?

No. There are various techniques you can use to embed data into an image starting from just embeding black-white images in the least significant bit of each color channel to more sophisticated methods to methods that only work for specific image formats etc. There are methods that require a key and methods that don't require a key (or passphrase).

Not all stegonagraphy uses images. You can use txt files, you can use html files, you can use word documents, you can use audio files... you can hide pretty much "anything" in "anything" - but it depends on how much secret data you can hide in non-secret data so depending on the methods you use you're limited in how much data you can hide.

If you want to know how each individual tool works... you gonna have to read the documentation of the individual tool and hope they document how they do it or you gonna have to read their source code.

Addendum:

People think data is somehow "typed" or has an innate format of some sort. But this is obviously false. If you see 8bits 10101010 you have absolutely zero clue as to what these bits represent. It could be a character, it could be 8 single bits, it could be 2 4-bit unsigned numbers, it could be a pixel in an image, it could be 8 pixels in a black white image it could be a 1 byte instruction. Bits have no inherent meaning. WE give them meaning by associating a type & encoding with it. That's why you can hide almost anything in anything.

You can hide text in html by abusing the fact that multiple spaces are rendered as a single space so when you open the file in a browser you see nothing. But these spacings you can use to encode bits. For example: 2 spaces -> 1 bit, 3 spaces -> 0 bit so this text in html:

This  is   a  short   text.

Which is rendered as

This is a short text

BUT

This  is   a  short   text.
     1    0  1       0

contains 4 bits of hidden data. You can give meaning to things in some format that don't have meaning in their intended format. Or you can abuse the fact that humans can't see the difference between a pixel 11111111 and 11111110 so you can use the last bit to encode your data.


Is cookie information stored on the server side?

This is a great security question. One must understand the mechanics of what they work with to ensure they are building secure software.

Security

There is no added significant security risk when a server has access to cookie information. Servers are already a privileged system that needs to be strongly protected.

  [Comment] ...how can [a] server identify a new request is from the same user as some
  previous requests, without memory of the previous requests coming from
  some user...?

If the server stores encrypted or signed data in a client-side cookie, the server can verify that. It can deduce that only an authorised server could have stored that cookie.

A good modern example of this is JWT - https://jwt.io/. They can be sent in a cookie, but typically they go into the authorization header for a Web API HTTP Request. If you understand JWT more, you can understand the cryptographic principles that can be deployed with simpler mechanisms for smaller amounts of data in cookies.

Knowledge

  how could a server match a cookie just received from a client to some
  session or other information created in the past?

Cookies are stored in the client's browser with a timeout after which they are deleted. Upon every HTTP request to the server, they are sent to the server automatically. The cookie is usually set by the server, not the client (but it's possible).

The server typically uses the direct value, or decrypts a value for a local database lookup. For example, the UserID value could be stored in the cookie encrypted.

A key architectural reason for using cookies, is to maintain a session linked to the identity of the user. They are also used as a type of distributed data store, so the server has this information already upon HTTP Request without having to look it up on disk/db which incurs latency.

A session might be associated with a key (GUID) in memory on the web server, or it could be a key for a new session record in a database. In both cases, the key is relayed by cookie.

  How does a server store cookie information?

The server MAY store them, but that's not how people view them conceptually. In a way the server does store the data - a session key is the primary key of a record (database or hashed dictionary lookup). For an encrypted UserID, the server-side does have they key too. In a way, the client isn't "storing" it, it's more like a copy of a key. But it is possible, and likely occurs, that clients store distinct information that isn't persisted on the server-side.

  is it true that a server always has records of cookie info?

No. Here are some scenarios where the server doesn't have records of the cookie info:

Javascript on the client-side sets a cookie. Eg. "OrganisationID=10" indicating that the user has changed organisation context across all browser tabs.
Server encrypts some data for the user to hold onto. Eg. "Roles=Admin,Developer,Staff" so that the server can enforce roles on functions without needing to do a lookup on the database

Although the server-side doesn't always have that information somewhere it usually does, because cookies are used for context. When there is a HTTP Request, the server needs to know who it's coming from, what roles they are authorized to use, and whether they have been seen before.


At which point can a system be compromised when downloading archived data from an untrusted source?

1 should not present any danger as long as the file is just saved somewhere and no attempts to open it with anything are made. If you view it even with a text editor, there's already a small danger of exploits.

In the case of 2 there are vulnerabilities and exploits, so there are dangers. Some examples of such possible scenarios:

Arbitrary file writes caused by .tar.gz archive symbolic link (symlink) vulnerabilities that are exploited because of how Bower (a popular web package manager) extracts such archives
CVE-2018-20250 is an absolute path traversal vulnerability in unacev2.dll, the DLL file used by WinRAR to parse ACE archives that has not been updated since 2005. A specially crafted ACE archive can exploit this vulnerability to extract a file to an arbitrary path and bypass the actual destination folder. In its example, CPR is able to extract a malicious file into the Windows Startup folder.
CVE-2018-20252 and CVE-2018-20253 are out-of-bounds write vulnerabilities during the parsing of crafted archive formats. Successful exploitation of these CVEs could lead to arbitrary code execution.
Zip Slip which attackers might use to target files they can execute remotely, such as parts of a website, or files that a computer or user are likely to run anyway, like popular applications or system files.
Helm Chart Archive File Unpacking Path Traversal Vulnerability.
CVE-2015-5663 - the file-execution functionality in WinRAR before 5.30 beta 5 allows local users to gain privileges via a Trojan horse file with a name similar to an extension-less filename that was selected by the user.
CVE-2005-3262 allows remote attackers to execute arbitrary code via format string specifiers in a UUE/XXE file, which are not properly handled when WinRAR displays diagnostic errors related to an invalid filename

There are plenty more examples and databases with such vulnerabilities and even most of them got fixed in later versions of the software, a risk still exists.

So therefore, [2] is risky and should be handled with care.


Sharing account verification tokens to third parties

Your requirement to provide verification codes through other channels than just email is quite sensible – but so is your concern about security. Unless you take extra steps, everyone who can intercept such a token can take over accounts. This holds for email as well as any other channel. In this case, routing verification codes through another company's service means that people who have access to the systems of that company could take over accounts. This could be malicious employees, but also attackers who have taken over the other company's systems. Of course, all of this applies to your organization as well.
So the question is what reasonable security measures can be implemented.
A lot of such reasonable measures will happen on an organizational or contractual level. For example, that other company might provide contractual guarantees to implement certain security measures, and might submit to regular audits. What would be appropriate depends on the sensitivity of these accounts: email, financial or health stuff usually but not necessarily more sensitive than an online game. This also depends on other regulatory requirements, e.g. GDPR.
You may also be able to implement some technical measures to increase security. However, in your scenario the other company mediates between you and the user so they could spoof any security measures if they wanted to.
Notably, any verification tokens you create are entirely useless.
The other company could just send the token back directly without performing verification.
Equivalently, your API with them could simply contain a boolean isValid field, which would have the same level of security from your perspective: none.
Maybe, changing the viewpoint could constitute a solution:
these are the other company's users, you merely implement white-labelled services for them.
Then, you should be providing security guarantees to the other company, not the other way around.
Whether this viewpoint is appropriate depends a lot on the specific services you provide.
Alternatively, strongly reconsider the flow where the third party performs the entire user interaction. If you can interact directly with the user but only outsource delivery of the token via the third party, that could significantly increase the security. For example, you could then ensure that the token was generated and consumed in the same browser session.


Is there a spreadsheet/template for Mapping WebServices Authorization Rules?

Oh uggh!  It's an interesting problem, as some of the bigger LDAP providers (that's you AD!) don't even recognize services as securables and IMHO they really should - IFF you have the ability to use some standardized LDAP provider for role management, then you can trawl a lot of vendor offerings for tools to help you in this -  bottom line is don't roll your own authorization, try and piggyback onto an existing LDAP provider where you can set up OUs, groups, etc to handle this for you and then use standard tool chains to monitor/report this
One other point - try and create the tables people refer to at the time they demand them, don't store stale copies -  people come and go, apps come and go, authorizations change


Why has Ubuntu 18.04 moved back to insecure Xorg?

They are doing this because the next release is an LTS release, which means stability is the primary concern. Xorg has a good track record of stability, whereas Wayland is still (relatively) new. This decision is not permanent and does not mean Ubuntu has given up on using Wayland, just that it has delayed it. You can also opt to use Wayland instead of Xorg if you would like.
From Ubuntu Insights, the three primary reasons for using Xorg by default are:

Screen sharing in software like WebRTC services, Google Hangouts, Skype, etc works well under Xorg.

Remote Desktop control for example RDP & VNC works well under Xorg.

Recoverability from Shell crashes is less dramatic under Xorg.

You will still be able to use Wayland and it is still pre-installed:

The Wayland session will still be available, pre-installed, for people to use, but for our ‘out of the box’ users the Ubuntu experience needs to be stable and provide the features they have come to expect and use in daily life and Xorg is the best choice here, at least for 18.04 LTS, but for 18.10 we will re-evaluate Wayland as the default.


How to properly transition from standard PGP keys to using subkeys?

You should be able to add the additional subkeys to your master key pair, while still leaving the master keys intact. It doesn't matter if the "master keys" have been used for a while, you don't have to generate new master keys to add subkeys to it.

You linked to the article I usually recommend which describes this process, of using gpg --edit-key <key>, and then addkey. Once you have generated the subkeys, hide the private half of the master key in a safe place and just use the subkeys from now on (only bringing them out for "special occasions" such as singing other people's keys, revoking, or adding new UIDs or subkeys).

  I don't want all of my emails which I signed previously to no longer be valid.

That won't be a problem; old emails should still show up nice and signed. The only way old emails that you signed previously can become invalid is if your master key that you signed them with gets revoked or expires. So long as the new signing keys are subkeys of your old keys, anything you sign with the subkeys will still show up as being signed by "your" key.

Encryption on the other hand might be a bit trickier. If you have used your master keypair for encryption in the past, you will still be able to decrypt your old messages, but you will have to fish out your master secret key from its safe place every time you do so.


Practical security for an inexperienced database developer? (HIPAA)

Any comprehensive solution is going to require depth, i.e. security in layers. Aside from hardening the system, restricting network access, having a substantial logging, auditing, and SIEM approach, you'll want to protect the data within the database as well.

Obviously protect any login information with a strong hashing algorithm like PBKDF2 w/ HMAC/SHA-256 and 100,000+ iterations or bcrypt or scrypt. MD5 or SHA-1 with single iterations is effectively plaintext, even with salting. Bcrypt will take care of the salting problem and the adaptive cost problem as well.

For HIPAA specifically, protecting PII is crucial. For sensitive information that you must be able to recall, strong encryption is a must (AES-128 or 256, using CBC, CTR (with unique nonces), or GCM mode recommended). Proper key management is also critical. Using a DUKPT system or some other transformative key derivation scheme to reduce key overlap or (ideally) an HSM to manage and protect the keys is a strong move in this regard.

For information that is sensitive but not required to be retrievable, but merely searchable, a strong cryptographic hash function (CHF) like SHA-256 (or even better, HMAC/SHA-256) will allow you to do (non-fuzzy) searching against that data in queries while protecting it at rest. This is less common in enterprise environments but for HIPAA concerns it should at least be evaluated against your performance needs.

If you have more specific questions, feel free to comment here. If they're self-contained we can answer inline but larger ones probably merit their own question on the site.

Oh, and never roll your own crypto. There are C# or .NET libraries written by professional cryptographers and cryptography developers to do anything you need. They are audited, updated, and have a high number of eyeballs on them. BouncyCastle is probably the best known.


Is encrypting localStorage data more secure?

An attacker has full control over the client, and therefore has complete access to the encryption keys and methods. In short, this cannot actually protect anything from an attacker.

Normally client-side encryption at least provides a small layer of protection to slow down attackers, but protections around client-side JavaScript tend to be the easier to circumvent than similar steps in apps or desktop applications.

It is unlikely to be helpful


A "padding oracle" is an entity (usually some sort of server) that will decrypt an arbitrary message, verify whether the padding is correct, and return this information to the (arbitrary) submitter of the message. If there's no such entity in your scheme, you cannot have a padding oracle attack, as there is no padding oracle to use for the attack.

Other relevant points:

You don't specify a padding scheme that you're using. In practice the openssl command will use PKCS#5, which is a padding scheme that can be used to detect trivial tampering with the ciphertext (though it is not reliable at this), and is therefore applicable for a padding oracle attack, but other padding schemes may not have this property in which case a padding oracle couldn't even exist.
You mention an HMAC, but not how it is used. You say it's the HMAC of the ciphertext, which means the verification must also be performed against the ciphertext. In practice, this almost always means that the verification is performed before decryption. Since the HMAC will fail to verify, hopefully the ciphertext processing would halt before getting to decryption (which comes before you can check padding). In such a scenario, even if you had a padding oracle a modified message would never reach it, because it would fail at the HMAC check. (Note that HMACs of the plaintext, which of course cannot be verified until after decryption, do not have this property, are much more likely to be vulnerable to a padding oracle attack).


... possibility of somebody sniffing traffic on this WAN

If you fully control every part of the WAN then you should know if somebody can sniff or not. If you don't fully control every part you should probably assume that somebody is able to sniff, even if the routers are directly connected, i.e. no router, switch or something like this in between. It is still possible to intercept traffic directly by splicing the line and adding an interception device, no matter if you use Ethernet, fiber or similar for the WAN.

  If my traffic is already encrypted before entering the tunnel may it be considered secure ...

It can be considered more secure then unencrypted traffic but it depends on the details if it can be considered secure enough. These details are for example the quality of the encryption or if sniffing of meta data (who connects with whom, how long, how many bytes...) is considered a risk which need to be addressed or not.


You have a couple options:

Use something like WCCP and function transparently
Be an inline proxy, as it seems you are now.
Use WPAD to send the devices to a box hosting your PAC file.
Manually specify the proxy in your clients.

However, this all depends on what you're exactly running, and if your devices support it (Can blenders handle PAC files?).  If possible, I suggest using WPAD, but you should be aware of MITM vulnerabilities.

Also, to address your question about dropping TCP/UDP packets which aren't proxied, just drop everything that doesn't have a source of your proxy, at any point after the ingress interface of the proxy.  Unfortunately, if you want to do this with a separate device, that device will have to reside between your proxy and modem.

You can also set your proxy up to do it by either using iptables on your proxy egress interface, or you could just not route traffic outbound for other internal devices... But the second solution would also extend past TCP/IP to include ICMP, IP Protocols, etc.


It's there a way to bypass https nowadays?

This depends on the capabilities of the attacker and the target website. If the target website was never visited by the victim with the current browser or if the target site did not employ HSTS then attacks using sslstrip are still possible.

Beyond that stealth MITM-attacks are still possible if the victim has a CA installed as trusted on its system where the private key is known to the attacker. This could be certificates installed by the vendor, like in the case of the SuperFisch software installed by Lenovo or the CA certificate installed by Dell. Usually such known compromised CA certificates are blocked but the recent disaster with a software for secure communication between lawyers shows that even large vendors are still unaware of these problems and thus will install new CA certificates on the system with a badly secured private key. And such CA certificate could also be installed by (often ad-injecting) malware, like in case of the recent OSX/MaMi malware.

Apart from that there are attacks possible using browser extensions which simply bypass breaking HTTPS since they have access to the plain traffic. In the past multiple innocent browser extensions changed their behavior and went rouge, like described in When Browser Extensions Go Rogue.

And then of course the attacker might use vulnerabilities of the system or use social tricks to make the user install some malware, which might install a new browser extension, hijack the browser or just replace it. This way the attacker too gets access to the plain traffic.


Clarifications regarding testing the cipher using NMAP scan

<table key="TLSv1.2">  is not configuration. The section you are referring in the NSE script explain the expected XML output.
ssl-enum-ciphers.nse script will enumerate through all tls.PROTOCOLS and then enumerate through all tls.CIPHERS to do the required checks.
tls.lua defines the supported protocols and supported ciphers.
My guess is that the NMap version you are using has tls.lua with TLSv1.2 included, but the ssl-enum-ciphers.nse is not updated with the TLSv1.2 related example outputs. It is anyway best to build latest version of NMap by using the source.


Can VeraCrypt encrypted volume be tampered with?

Yes it can.
This is very easy to verify for yourself:

Create a small veracrypt container of 300 KBytes.
Place a known file or files in the container.
Close the container.
Using a hex editor, edit a few bytes of the closed encrypted container (avoiding the header section).
Open the edited container with Veracrypt.

Depending upon the luck of the draw, you may see absolutely nothing upon opening the edited container, or you may see something bizarre. In either case, Veracrypt likely did not complain.


Why is a child window allowed to change the location of its parent?

I do not think that this violates the Same-Origin Policy, because the child tab is not able to access the data in the parent tab or modify it's content.
This was probable designed like this in order to allow the web developers to offer a better user experience when dealing with multiple windows.
On the other side, this is definitely something a web developer should be aware of and only use target="_blank" when this specific functionality is required.
It is easy to protect against this kind of attacks and most big websites (google.com, twitter.com, etc) do this by opening links in new tabs with the window.opener property set to null.
This has been reported as a bug to the Chromium team, but it was marked as WontFix because it was not considered to be a bug:

The user decides to trust a particular tab by inspecting the URL and determining the origin.  In all cases here both tabs area always showing the correct origin for the content being shown.
On android, when entering any data into a form, the origin is always shown, even if it's previously been elided by scrolling down.  The user can then make a trust decision based on this visible origin.
Given this, I don't see any risk to users more than the users just clicking on a link and visiting a new page, so I am closing with WontFix.

Link


Is using an access token for authentication a bad idea

If the user has a malicious browser extension, then there is nothing that a site owner can reasonably be expected to do to secure that user's information.

Properly using session and access tokens to identify a user after authentication remains the best practice, even when the user's machine is compromised.  This OWASP Session Management Cheat Sheet gives a good overview of these best practices, and the OAuth standard is battle tested for most general-use identification purposes. Secure the token as securely as you can, and remember that you can't blindly trust the remote machines.


TLS: is authentication and forward secrecy possible without PKI?

There is no need to use a PKI with TLS. The only thing a PKI does is to make the authentication part of TLS scale. When using self-signed certificates, PSK or similar all trust information (like certificates or pre-shared keys) need to be distributed to every communication peer in a secure way. These information need also be be kept up-to-date, i.e. when new communication partners get added, secrets gets compromised or similar. Using a PKI instead this process is reduced to sharing the trust anchors (root certificates) which rarely need to be updated and to regularly check if a certificate got revoked. Using PKI thus gives you an easy creation and sharing of new trust information and also revocation and replacement of compromised trust information.

If you already have full control over all communication peers and also have a secure way to distribute new trust information and also revoke these if compromised then you don't need to use a PKI. If you don't have this infrastructure yet then using a PKI might be the easier and probably more secure than implementing everything yourself.

As for the specific protocol stack you mention: While PSK/SRP authentication can be used in theory with DHE/ECDHE as key exchange as dave_thomson@ correctly pointed out in a comment below, these ciphers seem to be rarely implemented. But with certificate based authentication DHE/ECDHE is commonly used and self-signed certificate don't need a PKI either. Also, while AES with SHA-256 is secure ciphers using AEAD like the GCM ciphers are preferred today. And ECDHE is preferred compared to DHE.

  And if the SRP/PSK password of a client is obtained by a third party will he be able to eavesdrop on other clients?

If the essential secret (pre-shared key, password, private key) is obtained an attacker will not be able to decrypt sniffed data if DHE/ECDHE is used for key exchange. I'm not sure how PSK/SRP key exchange behave in this regard. But in all cases the attacker can impersonate the peer and get access to the decrypted traffic inside a man in the middle attack. Since the attacker has the secret this can be done without the other party realizing the problem, i.e. the authentication still succeeds. This is one of the reasons revocation and replacement of such secrets needs to be implemented - which is already included in the PKI.


Set up Domain Keys Identified Mail on your own domain.  That will digitally sign legitimate outgoing from your domain.  More and more email providers are rejecting or flagging spoofed email where legit email is identified with a Domain Key signature.

Your question says, "apart from SPF..." and that's what I answered.  However, for others who might use this answer, SPF is another deterrent.  It is easy to set up, but has some limitations that should be considered carefully.  You probably want to start with a SOFTFAIL policy.


Is accessing by IP address without CA certificate secure?

No, that isn't secure.

The IP vs. domain issue is irrelevant, the problem is that you're telling users to click through the certificate warning. This means that an attacker can simply self-sign their own certificate and perform a man-in-the-middle attack, and the user will click through that.

If you control your users' systems, run your own internal CA and install your CA root on the users' systems. This is the industry standard method for implementing secure TLS on internal servers.


There are two distinct semantics that the nextUpdate field is used to convey:

the date at which a newer CRL should be available, thus making it worth a new download (similarly, before the date given in the nextUpdate field, a cached CRL should be considered to be the newest);
the date after which a given CRL should be considered obsolete.

It is expected that CRL overlap, so that transitions are smooth and network traffic spread throughout the day. Typically, a CA would produce a new CRL every hour (so that fresh information is available) but would "allow" a given CRL to be valid for one day (24 hours). Since a CRL can be somewhat large, downloading it is expensive, thus implementations would prefer not to do it too often if it has no practical use. But since each CA has its own policy, a generic certificate validator cannot know a priori what kind of schedule a given CA uses; it must learn it through the data in the certificates and CRL.

The first meaning is what X.509 mandates. However, everybody uses it with the second meaning. In effect, implementations of X.509 (e.g. in Web browsers, when they validate the certificate of a Web server) handle nextUpdate as if it was an endOfValidity date. Lately, Microsoft has defined a new extension called nextPublish which assumes the first meaning (the extension can be seen in annex A.1 of this draft, in an OCSP context). This extension (which seems to be, so far, private to Microsoft, not standard) somehow acknowledges that the common practice deviates from theory with regards to the meaning of nextUpdate.


How do I keep the PDF files in OneDrive secure?

If bruteforce or dictionary attack is your concern, you can defend against this by ensuring that the key derivation is suitably computationally intensive to make it infeasible for an attacker to crack the password, while leaving it reasonably convenient for you to decrypt them.

For example, KeePass allows you to store files in password vaults. It's primarily a password manager, but the vault file format is also suitable for files. When creating the vault you can specify the number of rounds for key derivation.

Clicking the "1 second delay" button gives you a round count that will take 1 second to compute on your current machine; multiply this number by however many seconds you want it to take. If you pick a round count that takes ten seconds to compute on your system, even attacker with ten thousand times your computational resources could only try a thousand passwords per second, which isn't really a lot if your password is suitably complex and non-dictionary.

If you're looking for a more traditional option, consider using 7-zip, as it performs key derivation using using 219 iterations of SHA256 (source) by default.


Is it safer to send cookies in headers than the URL?

Putting an auth cookie value in the URL is a bad practice because it can be retrieved in the following locations (whether or not your are using https):

Referer Header
Web Logs
Shared Systems
Browser History
Browser Cache
Shoulder Surfing

So there is more risk that a third party impersonate the user session.
You should consult the OWASP about this case : https://owasp.org/www-community/vulnerabilities/Information_exposure_through_query_strings_in_url


You've already taken the most important first step to protecting yourself, and that it to recognize that caller-id information can be spoofed, and is not entirely trustworthy.  The second step is to apply that knowledge, and stop relying on caller-id.  If someone calls you and asks for personal information, even if the caller-id appears to be the legitimate number for an organization you trust, don't assume that it's true.  Call them back at a number that you can independently verify is correct.

As to recognizing when caller-id is being spoofed, generally no, you can't.  If there were a fail-safe way to do this, then swatting would be impossible, and we know from experience that it is not.


Accessing document using a 6 letter token

Brute forcing

So you have an alphabet of size 36 and 6 characters. That gives you about two billion different tokens. Lets say you have a thousand different documents. That gives you a chanse of one in two million of guessing a token associated with a document. Trying from a thousand different IP:s every hour for a year would give you almost ten million guesses - that should give you a couple of documents.

Sure, the CAPTCHA makes this harder. But they are not perfect, and they can always be cracked by humans.

The problem here is that since you only enter a token and no document ID you can only rate limit on IP and not on document. That makes it very hard to protect against brute forcing unless you have a very large space to pick tokens from.

Sharing

A password is personal and you are encouraged not to share it. That means it can be easily changed if it is compromised, and you have some control over who gets their hands on it.

A document token like this is supposed to be shared by design. You have very little control over who gets it. It will end up on mailservers and backups and post its on peoples desktops all over the world.

You have no idea who has access to the token, and if you need to change it you will need to redistribute it to all the persons who are supposed to have it. That is neither secure not practical.

Conclusion: There must be a better way

This will not give you very good security. If the resource you are protecting is not very important it might be enough, but I would not use it for anything of value.

I do not know your exact use case, but whatever it is there must be a better way to solve this problem than rolling your own API. Using an existing solution would also save you the problem of having to write your own code.

Use an existing cloud storage service, a VPN connection into the company intranet, or something else. Just don't fire up your IDE and start coding away.

Update: Your use case

This is one of the cases where an access token is probably a good idea. But to get around the problems mentioned above I would do this:

Keep both the CAPTCHA and the rate limit by IP. (You might want to reconsider how the rate limiting is done in order to prevent accidental or deliberate DOS.)
To deal with the brute forcing, I would increase the size of the token. Google Drive uses 49 characters with both upper case letters, lower case letters and numbers. That should be enough for you as well.
To get around the sharing issue, print the URL with the token in a QR-code on the document itself. This brings the hole problem into the domains of physical papers that peoplpe are used to dealing with. The people who see the paper will have access to the digitial original. That is easy to grasp.
Consider setting a limit on how many times the document can be accessed, or at least a maximum time for how long the token can be used. If the car should be registered within one week, there is no reason for the token to work after two.
Do not store the tokens in plain text in your database. Hash them. (Something fast like SHA256 should be enough here - no need to roll out bcrypt when you have large random tokens.)
Use a CSPRNG to generate the tokens, otherwise they could be guessed by an attacker having access to a few tokens.


Risk of Production Data in Test / QA Environments

The risks are essentially that you have far less control over a development/test environment, more people will have access to larger portions of the data, and it will be used and thought of in a far different way.  Test data often needs to be sent to 3rd parties, across oceans, or other places where you have no control over it.

Essentially, count on your test data getting out of the database in one way or another via screenshots, email, etc.  This doesn't have to be malicious and largely isn't.  For the most part, it will be people merely trying to get their job done.

If the data is senstive in nature like medical records, you need to anonymise the data in some way, but still make it reflect production.


Does changing the scrypt salt have security implications?

No, there are no implications. From what i know, scrypt is not vulnerable to differential cryptoanalysis.


After digging a bit, I found the same url mentioned in another mentioned on another StackOverflow question that match OP's description :
http://ums.adtechjp.com/mapuser?providerid=1074;userid=AapfqIzytwl7ks8AA_qiU_BNUs8AAAFYqnZh4Q

So your link might be from an adtech{countrycode}.com domain. According to Wikipedia :

Adtech AG is a German–American digital marketing company that retails products to manage, serve and evaluate online advertising campaigns (including display, video and mobile formats). The company was founded in 1998 in Frankfurt, Germany, and was acquired by AOL on May 15, 2007.
Adtech provides an integrated ad serving platform. This product allows publishers, advertisers, agencies and ad networks the ability to manage their display, video and mobile digital advertising campaigns.
Adtech's ad server responds to banner requests, prompted by user’s browsers, through XML and delivers it to the specified end system — the only provision being the terminals must be online.

So, my theory is that your browser alerted you about the said url because :

The domain is extremely shady.

Depending of the individual/company behind the link itself, it might actually be a spyware like this one.

Now that's kind of a blind shot, as OP didn't mentioned what kind of file was downloaded but well, it's an ad network, so there's clearly no reason to download nor to open the said file.


Firstly, you are right, it is a recursive problem.  SSL is sort of a house of cards because you always have to trust something, including the folks that are telling you who to trust.  A number of experts have predicted the collapse of SSL:

Security Collapse in the HTTPS Market

SSL/TLS encryption and the vacant lot scam: Too big to fail

How is SSL hopelessly broken? Let us count the ways

SSL and the future of authenticity

That being said, it is all we have for now, so panicking won't help.

If you're concerned that the program that you just downloaded also installed some malicious root certificates, there are scanners available to check them, such as this one and this one (Note: I can't recommend any of these because I haven't tried them, so do your research).

Or, if you wish to scan them manually, a pretty good list
is maintained by Microsoft's Trusted Root Certificates Program.


As @AndrolGenhald points out, the words "Reset password functionality" usually means the "I forgot my password" workflow. The idea of having "Reset password functionality" that can only be accessed by a logged in user does not make sense.

I will assume you mean "Change password functionality", like when you press ctrl+alt+del in Windows.

I think the only field that is mandatory is a "Confirm your password" or equivalent. If your app supports multi-factor authentication (aka MFA / 2FA) then you should force the user to go through the full login workflow again before presenting them the "change password" form. The idea is that finding someone else's laptop unlocked should not be enough to change their password.


In golang TLS, if an intruder obtains the client cert and key, is MITM possible?

The certificate in TLS is used for authentication, i.e. to verify that one is talking with the expected peer. This is true for both server and client certificates. But in most cases only a server certificate is used to make sure to deter man in the middle attacks. Thus most MITM scenarios only care about somehow faking the servers certificate or stealing the servers private key to perfectly impersonate it.

In the case that only the client certificates private key is compromised but not the server certificates private key a man in the middle attack is not possible, provided that the client correctly validates the servers certificate. And it does not matter if both certificates are signed by the same CA or not.

But, if the client certificate is used by the server to authenticate the client and based on successful authentication to allow specific activities, then another attack is possible. Since the attacker has compromised the private key of the client certificate he can now perfectly impersonate the client and do any actions at the server which are allowed for this certificate.

The situation is different if the client wrongly relies only on the trust chain for certificate validation and does not check that the subject of the servers certificate matches the servers name. This error of not checking the subject or not properly checking it could actually be found often in the past. In this case the attacker could use the compromised client certificate to fake the original server certificate inside a man in the middle attack because this certificate is signed by a trusted CA and the wrong subject is not detected by the client.


What are the problems with uploading client-side encrypted keys to keybase.io?

Assuming that your private key is actually encrypted on the client side, what is the problem with uploading it?

The private key is usually encrypted (but not necessarily). Anyway, a private key is much stronger than a "normal" passphrase and enable brute force attacks against the private key. Sharing the encrypted private key would actively harm your security.

The encryption of private keys with a passphrase is more to be considered an additional protection against accidental leakage and not meant to be a safe way of sharing it with the public (or any other untrusted entity like keybase.io).

But there's more to it: there is no real use in sharing your private key. All cryptographic operations involving others are based on the fact you only need to share (and should share) the public key. Encryption of messages to you is performed using your public key (and the private key is only used for decryption), signatures issued by your private key are verified using your public key. If everything you want to achieve is sharing your private key amongst your own machines, better choose a way that does not involve non-private channels like "cloud" services. Remember the private key changes very rarely, and putting some effort in offline transmission usually should not be an overly large hassle. Consider using subkeys to make key management easier.


Key derived from source files; deduplicated file storage

No, this is not generally secure. You cannot have deduplication with other users' files and privacy. But this depends on your exact threat model/security goals.
Using the hash of a file to encrypt it is called convergent encryption, and is a deterministic encryption method. Notably, there is no secret key that would add security to the ciphertext. Instead, any security comes from the entropy in the plaintext files alone.
It is clear that this scheme can't offer e.g. semantic security, and an attacker can efficiently learn something from the ciphertext. In particular it is trivial to verify if one of your files matches a publicly known file. Furthermore, PDF documents such as form letters might look high-entropy, but actually only differ in a few fields. This can be brute-forced. Also, a malicious service provider can pre-compute encryptions of documents they're interested in.
The solution of this is to stop using a deterministic encryption method. For example, adding a sufficient amount of random bits per block/file will help, but will also destroy deduplication opportunities. Using a real symmetric encryption with a secret key would be another solution, and would at lesst allow deduplication among holders of the same key.
You claim that your plaintext has high entropy. This is a strong assumption. Note that if your plaintext is high-entropy, then deduplication is unlikely and you might as well use a secure encryption method instead. In the context of this discussion, entropy must not be understood relative to all-zero bits but relative to the distribution of content known to other participants. If every user knows 1000 files of which one is the same 2GB large movie, that file only has around 10 bits of security, or actually zero since a fingerprint for the convergently encrypted file can be precomputed by everyone. Since your scheme doesn't feature secrets, it is impossible to distinguish between legitimate users and malicious attackers.


Can my smartphone apps that I am using be seen in the router?

Some apps will use insecure communication (HTTP) and then your data will be visible. If you have a Mobile Device Management solution such as Intune, it will also report the apps you have installed and might install an SSL certificate to strip your traffic.

Also, the destination of the traffic can disclose information on the apps being used. If you want to stay hidden from a network admin, you can best use a VPN tunnel or Tor (But TOR will be a big red flag in a decent company). VPN and Tor communication can be blocked in companies.


What policies maximize incident detection (and compromise detection)?

The policy that improves incident detection is a policy to equip security staff with automated monitoring tools that save them from the tedious legwork of scouring log files and performing manual detection. By analogy: you don't improve physical security by asking your guard to walk faster, you give him CCTV monitors.


Public Key Certificate Pinning and MITM attack

During the initial TLS handshake, a "master secret" is created

  The client and server then use the random numbers and PreMasterSecret
  to compute a common secret, called the "master secret". All other key
  data for this connection is derived from this master secret (and the
  client- and server-generated random values), which is passed through a
  carefully designed pseudorandom function.

As this secret is used throughout the communication a MiTM attempting to impersonate either the client or server mid-conversation would need to have the master secret (and likely other secrets) to encrypt and decrypt communication. But being that this secret is only known by the original client and server, a MiTM is impossible (or at least very difficult).


Local Burp Proxy not showing routed packets

I had the same problem .
This solved my issue:

Modify the /etc/hosts file .
Change this 127.0.0.1 localhost into 127.0.0.1 local.dev where local.dev can be what you like


Is the size of a packet sent through a Tor circuit consistent?

Tor sends data in cells, each of which is exactly 514 bytes long (512 bytes in the past, which is still reflected in some documentation). Any data that is transmitted through Tor will be in multiples of 514 bytes. If the data sent is smaller than once cell, the cell is padded with zeros.


Relation between boolean blind SQLi and time blind SQLi?

Whilst I don't think I can provide a concrete example my inclination would be to say that it is possible that there would be an instance of SQLi where boolean based injection would be possible and time-based would not.

The reason being that time-based injection usually relies on modifying the syntax of the query to add additional statements (e.g. WAITFOR DELAY) which may not be supported in every part of a query in every DBMS, whereas boolean based injection relies on inserting logical operators which are more likely to be universally supported.


A nonce doesn't have to be secret or unpredictable; it just can't be reused. It's perfectly fine to use an all-zero nonce one time with a given key. You just have to make sure you never reuse it, just as with any other nonce value you'd use. To be clear, this means a maximum of one message.


How to decrypt password manager vault without the password manager client?

The answer will be different for different password managers, but your question is extremely important.

Many password managers (including the one I work for) store your encrypted data locally on your machines for the non-browser clients. We explicitly encourage people to use a native client so that you can use your data off-line (among other reasons).

The scenario in which the service becomes unavailable will still leave you with working native clients which will be able to read your data. I find it hard to imagine a scenario in which you would still have your data but for some reason the native clients would be unavailable. Remember that there will typically be older versions of software "out there" and among your backups. (If you are asking this question, I also trust that you are making good backups of your down systems.)

Specifically for 1Password

I can give you a partial answer with respect to 1Password, for which I work.

Starting with the bad news is that we still don't have a robust and easy to use local data backup/export system that preserves the structure of the data. It is, of course, possible to export you data from 1Password, but it loses a lot of the structure of the data and isn't suitable for automatic backups.

The 1Password local data stored on your system is tuned for particular things about the platform and is subject to change. So, for example, if you took your 1Password.sqlite file used by 1Password for Mac it wouldn't be readable by 1Password for Windows. One from a year ago might not be readable with the current client. We need to have the flexibility to tinker with that data format. This is why an exporter/backup tool is needed instead of a reader directly for that data.

We've documented in great detail how our encryption works, but that documentation doesn't quite cover everything you need to know about the sqlite3 data stored on your machine. Indeed, it is the part that isn't documented that is subject to change.

As the core of it is all the same and conforms to what we've documented, it isn't too hard to reverse engineer the rest. Indeed, people have done so. Free (John the Ripper, hashcat) and commercial data recovery/cracking systems have tools to do exactly this. And we have always tried to assist those doing so when they ask specific questions about the data format.

This is hardly an ideal situation. The plan (though it has been a plan for a while now) is that we will provide a local encrypted backup format that is open and fully documented and which and preserves all of the item detail. This has been 90% done for a long time, but the last 10% has been taking a while.

But in the mean time, you can regularly use the existing export mechanisms and save those in a security location (as export isn't encrypted). Or rely on the fact that your own backups will contain versions of the 1Password app which can read the local data that you also have on your system backups.


How to prevent persistent XSS vulnerability with the Java Struts 1 Framework?

Don't know about Struts if it has some built-in protection, but you could escape (sanitize) the html tags, so that when the script tag is printed to the page, it won't be executed. You should put your sanitization code to the action controller where the form submits to.

Replace "<" character with &lt; and ">" with &gt;. After that script tags won't be executed.

OWASP XSS cheat sheet will help you to mitigate XSS vulnerabilities: https://www.owasp.org/index.php/XSS_%28Cross_Site_Scripting%29_Prevention_Cheat_Sheet

Or as @dandavis commented: a CSP would help to mitigate if you can't update the app logic.


Left my Facebook logged in - what could my employer see?

Without any traffic to the computer, there would be nothing to "see".
All that occurred was that a special key (and "authentication token") was left on the computer, so that when you visited Facebook again, it logged you in without you needing to enter your password again.


How long will it take to crack a 10-15 character winrar password?

There is some data here. WinRAR uses a custom key derivation function which involves thousands of SHA-1 invocations. Apparently, with two good GPU, about 15000 passwords per second can be tried.

Then it depends, not on the length of your password, but on the way you produced it. It's not the length which makes the password strong, but the randomness. If your password is a sequence of 15 random characters, chosen uniformly and independently of each other, then it will resist forever. If it is a common English word which happens to be 15 characters long, then it is toast and will be recovered in a matter of seconds.


What are the benefits of having multiple overwriting patterns for secure deletion?

No, it isn't necessary.

With modern (less than 10 year old) hard drives, it is not required to overwrite a disk more than once.

There is an often cited paper which says that you need to overwrite data at least 10 times to be sure, but that paper is over 20 years old and thus applies to outdated hard drives. Modern hard drives use much weaker magnetic fields and much more sensitive read-heads to reach higher data densities. As a result their data is a lot less persistent.

This has been proven in the paper "Overwriting Hard Drive Data: The Great Wiping Controversy" by Craig Wright and Dave Kleiman from 2008.

You might wonder: "Then why is there still software which offers to overwrite hard disks dozens of times with all kinds of sophisticated patterns?" The answer is that people are paranoid when it comes to security. When they heard somewhere that a hard drive can be restored after a single pass, even when the source is dubious, they won't trust a software product which doesn't do it. Also, there are some outdated standards for IT security around which still have that myth and which must be followed by some organizations, even when they know that it's snake oil.


double-new attack? replace contact method twice so that the "new" and "old" one are both attacker-controlled

I haven't heard of a name for this, but...

A better way to mitigate this is to have a transaction log, rather than just a pair of slots for old and new values.  The company's customer service will be able to see rapid changes to the contact information, and can rollback changes no matter how long the attacker has had control of your account before you found out.


Storing passwords in reversible form - a genuine use-case

In the case you've described you're storing information on behalf of the user, and you're not using it to authenticate the user. Hence, while the contents of what you're storing includes passwords (almost exclusively), you're not really "storing passwords" in the traditional sense. You're storing secrets.

Adjust your strategy accordingly.

Both of these problems are solved; you just need to apply the correct solution. When "storing passwords" (that is, authenticating the user), you go through the hashing, the the salt, the key stretching, etc., that you're familiar with. But what about storing secrets.

First and foremost, you avoid the problem if possible. This is why concepts like API access tokens exist. You don't need my Facebook password because you can't use it. You need an access token which Facebook is willing to give you with my permission.

The next best solution is to tie access to user login. The information is encrypted using a key derived from the password you use to log in - which I don't know and don't store. So I (the server owner) can't access your data unless you type in your password.

This is popular because it's powerful. In fact, Windows has been doing this for a long time, which is why changing your password can cause encrypted files to become inaccessible. It's also the reason why your Windows password is stored in plain text in memory while you're logged in. An implementation snafu which I would advise you to avoid.

Next on our list, you can separate your processes such that unencrypted data is never available on outward-facing machines. Bonus points if an HSM is involved. The gist here is that the user provides his secrets to the web server, which are quickly encrypted using the public key to some secret crypto device which is totally inaccessible because it's not connected. The plain secrets get immediately forgotten, and the encrypted data then gets shipped off to some cold storage somewhere.

Eventually the secrets get decrypted somewhere else with the assistance of that crypto thingy and get used. Only, the point where this happens has NO INTERNET ACCESS. Or at least no path from the outside in.

Finally, you can try the solution above, but fail miserably. I only mention this because really all other solutions are just crappy variations on the ones above: encrypting in the database, using an application password, storing the password on another server, storing the data on another server, salting your encryption key with [silly idea here], and so on.

And finally, my standard warning for questions like this applies. I'll write it really big:

  The fact that you're asking this question means that you shouldn't do it

Seriously. Storing peoples banking credentials? If you don't understand what sort of trouble you're getting yourself in to, if you're asking the Internet for suggestions on how to do this, if all the solutions I mentioned weren't ALREADY top-of-mind to you as the only viable options, then you shouldn't be implementing this.

People are trusting you to do this right. And you're not going to do this right. Not because you didn't ask the right questions, but because you haven't solved this problem often enough to understand what hidden pitfalls you'll have overlooked. This is difficult stuff: not difficult to do, but difficult to not make mistakes.

Don't betray the trust of your customers by getting yourself in over your head.


Cracking PCI terminal using a trojan based on the card

The backdoor that you are describing can be installed if you have code execution on the ATM.  This research, as well as methods of obtaining code execution on an ATM where pioneered by Barnaby Jack and are detailed in his BlackHat (and defcon) 2010 Jackpotting ATMs talk.


What threats does Android pose to anonymity when internet is accessed by a laptop through USB tethering but over Tor?

As already mentioned in a comment, your phone is an intermediary to the same extent as our phone's ISP. They see exactly the same traffic. Therefore, any technology that protects you from a hostile ISP protects you equally from a potentially hostile phone.
This is under the assumption that the only thing that the phone can see is the network traffic from the laptop. There are actually two ways the phone could be a more powerful attacker. Neither are due to the fact that the laptop's network traffic transits via the phone, only to the fact that the phone is located nearby and connected to the laptop via a cable.

If your laptop's USB stack is buggy, it might allow your phone to attack your laptop. The best remedy is to have an up-to-date operating system (and hoping your adversary doesn't have  a zero-day on the OS drivers) and secure USB firmware (which you don't really have any control over, so don't obsess about it).
A smartphone has a lot of sensors which can observe all kinds of side channels. For example, malware on the phone may be able to figure out what you're typing from the sound of the keys being hit.

This is movie-plot-level paranoia, well beyond FBI-level attackers, but possibly not beyond NSA-level attackers.
Tor protects you by routing all traffic through an encrypted channel so that any intermediary between your laptop and the Tor network (your phone, your ISP, connections between ISP, the Tor entry node's ISP, the Tor entry node) can see that you're using Tor and can see the volume and timing of data, but not the content nor the ultimate destination of the data. The usual limitations of Tor apply (traffic between the exit node and the ultimate server, a state-level actor that sometimes controls both the entry node and the exit node that you happen to use at that time and manages to correlate packets through timing, occasionally forgetting to use Tor, etc.). None of these limitations are made any worse by having a smartphone as the first network gateway out of your computer.


After heartbleed, how can you safely distribute new certs?

Normal, serious root CA are offline. They are hosted on machines which are never connected to any kind of network. This tends to make them immune to remote attacks, and that's the point.

Technically, the reasons which have warranted key renewal ("the bug was there, so there might have been a compromise that we don't know of") are still valid: it would be preposterous to claim that we found and removed the Last Bug Ever in OpenSSL, or, for that matter, in Apache (OpenSSL is a library, it is loaded in the address space of the Apache server, so any similar bug in Apache itself would be equally devastating). So there must be some remaining bugs, and your new key is as "potentially compromised" as the previous one. So don't sweat it...

Or said otherwise: the whole heartbleed panic is based on a suspicion of possible breach, which logically still applies, and has always applied since the first days of networks. The "heartbleed" bug is nothing qualitatively new; bugs with that level of seriousness are found several times per year in any significant piece of software. We can conclude that "we cannot be sure of anything" and that would be mathematically true, but impractical. If we want to cling to the idea that computers and networks are still usable, then we must accept that bugs exists, some of them being vulnerabilities, and that usual strategies (applying security fixes as soon as vendors publish them) is a valid strategy which will allow our servers to remain unscathed most of the time.

As a colleague of mine told me yesterday: fish group into swarms (technically called shoals and schools) to protect themselves from predators. When a dolphin grabs a fish, that specific fish probably thinks "why me ?" and has a feeling of injustice; but the shoaling strategy is still effective on average.

To a large extent, that's what we do with the mechanism of vulnerability publication and security patches. A vulnerability may be found because it has been observed to be used by a predator, and that's too bad for the victim, but at least the rest of the swarm benefits for the experience. We would really like to be more proactive and develop code with no bug, but alas Science has not come up with a way to reliably avoid bugs in software (though languages with strong typing and systematic array bound checks can help a lot).


You need the token to be sent in the request outside of the cookie mechanism (e.g. POST data). If sessions are managed via a session ID contained within a cookie, your approach doesn't prevent CSRF.

In your current implementation:

  save token to session;
  save token to client's cookie via Set-Cookie header.

This will have the effect of the token being saved in two locations, but both locations will be identified by cookie values.

e.g. if the token is "12345678" it will be saved in session (pseudocode):

Session["SessionCSRFToken"] = "12345678";

and in cookies

Cookies.Add("CSRFToken", "12345678");

However, in order to save the value in session, the web application framework will create a cookie to identify the session, so you will get two cookies set:

Set-Cookie: CSRFToken=12345678;
Set-Cookie: SessionID=987654321;

If a user is logged into your website at www.foo.com and then the user visits www.evil.com, there could be a hidden form tag embedded into the page of www.evil.com (possibly within a hidden IFrame) which is automatically submitted by JavaScript:

<form method="post" action="https://www.foo.com/Account/DeleteAccount">
</form>

When the browser automatically submits the form, both cookies will be sent with the request
(CSRFToken=12345678, SessionID=987654321) and your cookie token (CSRFToken) and session token (SessionCSRFToken) will match and the effect will be that the user's account is closed on your system without their knowledge.

To prevent this, you need to store a CSRF token in the page itself (e.g. within a hidden input). This way your form could only be submitted as follows:

<form method="post" action="/Account/DeleteAccount">
    <input type="hidden" name="CSRFToken" value="12345678" />
</form>

Now www.evil.com has no way of including the hidden input within their own HTML as they have no way of knowing the value of the CSRFToken. The value of CSRFToken can be the same as the cookie (the session value is now no longer needed), but it only needs to be generated once pre user session (there is no need to constantly regenerate the value).

For each POST you simply need to make sure that Request.Form["CSRFToken"] == Request.Cookies("CSRFToken").


If my password was able to be printed on a form sent home from my child's school, does it imply insecure password storage policies?

Yup! If they are able to retrieve the password from the database, then they are clearly not following password storage best-practices. OWASP provides a good guide for how to do it properly:

https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet

Here's some ammunition you could use in that letter:

You want me (the legal guardian of my child) to sign a form.
You are using the action of logging into a website and clicking a button as a form of legal signature.
How do you know it was actually me that logged in and clicked the button?
How many people had access to the sheet with the username and password on its way to me? How can you prove that it was actually me that logged in and clicked the button?
Clearly the password is stored in the database in such a way that it can be retrieved by school board staff. How can you prove that it was actually me that logged in and clicked the button?
Were something to go wrong, I highly doubt that "signature" would hold up in court, meaning the form will not hold up in court. This seems like a liability issue for the school board and/or for me (depending on what's in the form).
Can I get a statement from the school board's legal team that this is ok?


Is Ruby's SQL Injection protection enough to warrant not using additional security measures?

No all security measures have weaknesses at points in time. You always want to have layers of Defense-in-Depth and never rely only on a single security control.

A deeper comparison of how the two you mention perform may or may not reveal whether there is overlap in the protection mechanisms. It may or may not turn out to be that one of them completely overlaps the other such that the second may not appear to be providing much benefit at the time of analysis.

If both are actively being developed there will be many points in time where one solution eclipses the other such that having both will provide more protection than one by itself. Depending on the ecosystems for that product this may happen frequently.

My suggestion would be to do a deep evaluation of each product, learn how frequently they get updates (look at their past history if possible), and see if you can determine what all each of them are effective at blocking. If this is a new market you may want to re-evaluate them every few months in case one becomes much better than the other.

Finally, if possible it's better to have two totally different types of security controls rather than two controls of the same type. The reason this helps is if new classes of attacks completely void one type of defense there may be a situation where a secondary type of defense may still work. Likewise in many, but not all cases, it's helpful if the security control is running on a system in front of the server containing data being protected rather than on that system (if the control itself has a bug it doesn't drop the attacker on the box with the data).


HMAC needed with SSL/AccessToken in place?

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

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

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


I don’t know of any great solutions.  I can suggest three possible defenses, though all of them have limitations:

Privoxy. Privoxy can block ETag headers.
In particular, you can use crunch-server-header or server-header-filter in your Privoxy configuration to block ETag: headers from the server.
Also, you can use crunch-client-header or client-header-filter in your Privoxy configuration to block If-None-Match: and If-Modified-Since: headers from the client.  However, I don’t know of any off-the-shelf formula you can just grab and use: you’d have to build your own Privoxy configuration yourself.

Your browser. If you use Firefox, you can configure Firefox to clear your cache each time you exit the browser.  This may be bad for performance.  Also, with this approach, ETags can still be used to track you within any one browser session, so it is not perfect, but it should clear any ETag cookie when you quit your browser.

RequestPolicy. If you use Firefox, you could use the RequestPolicy extension.  One writer has pointed out that RequestPolicy may help defend against ETag tracking.  Often, web sites track you by including resources from third-party advertisers or analytics providers.  RequestPolicy lets you control what third-party resources your browser will request, when visiting a web page, and thus can let you protect yourself against that kind of tracking: if your browser never loads the third-party advertiser’s resource, then the third-party advertiser doesn’t have a chance to track you (using an ETag or any other mechanism).  This defense is less than ideal, because it requires you to laboriously assemble your policy, and because web sites can still track you directly if they don’t rely upon any third-party resources.

Unfortunately, if you access the web through a transparent proxy, the presence of the proxy may complicate your attempts to avoid being tracked.


What is the difference between "key length" and "bit strength"?

I'd use bit length for the size of something, such as a key.

I'd use bit strength as the base 2 logarithm of the cost of an attack. i.e. it costs about 2^n basic operations to break something.

A brute force attack against an n bit key that simply tries to guess the key costs 2^(n-1) calls to the encryption function on average, which lead to this convention of expressing the strength of an algorithm in bits.

Thus you could understand "n bit strength" as "Breaking this costs approximately as much as breaking a symmetric encryption algorithm with an n bit key."

But they differ in other cases. A few examples:

An RSA key with a length 2048 bits only has a strength of about 112 bits.
A hash with length 128 bits can only have 64 bits of collision resistance.
3DES takes a 168 bit key, but only offers 112 bits of security, due to a meet-in-the-middle attack.


How to check if a third party jar(JRecord) has any security issues

If its open source you can download the source and review it yourselves. You should then use the self-built version to ensure the binary supplied online is not malicious.

Beyond that and googling for known issues with the package there isn't anything much you can do.

*What review process do you have to ensure libraries pulled via Maven are secure? And how does this differ?


You can only use one key to sign the data…

… However, it's way more convenient to use 2 pairs of key (ZSK & KSK). There are 2 important points to take into account:

You need to regularly refresh the key (ZSK) used to sign the records. (For security reasons.)
You need to be sure that the DS record in the parent zone corresponds to the key used in the aforementioned zone.

This is very important, any error in the key rollover process would result in a total failure. And each time you would renew your ZSK, you would need to update the parent zone. This is why a KSK is used. This key will only be used to sign the ZSK (and itself). The DS record in the parent zone should correspond to that KSK. You don't need to renew the KSK as often as the ZSK.

The cool thing is that, with these 2 keys, you can renew the ZSK without updating the parent zone! To summarise briefly, you need to:

Sign the records with the new ZSK.
Sign the new ZSK with the current KSK.

As long as you don't change the KSK, you don't have to change the DS record in the parent zone.

The KSK of the .se zone is sent by the .se nameservers. The hash is sent by the parent zone, the root's nameserver in that case.

Here's briefly how DNSSEC works:

The resolver gets a record, along with its signature (RRSIG) signed with the zone's ZSK.
To allow the resolver to check that signature, it also gets the ZSK, and its signature (RRSIG) signed with the KSK.
To allow the resolver to check that signature, it also gets the KSK, and its signature (RRSIG) signed with the KSK. (self-signed)

You can see that, if you trust the algorithms used, everything is as secure as the KSK is. But the KSK is sent by the same nameserver that sent you the record! It could seem pretty useless, but not really…

The resolver gets from the parent zone the DS record for the aforementioned zone. This DS records is a digest of the aforementioned zone KSK.

As you can see, as long as you trust the parent zone, you can trust the KSK used, and thus the record.

That's how DNSSEC works: that DS record is also signed by the parent zone ZSK, like the record was in the child zone. You check it with the ZSK, the KSK, and the DS record of the parent of the parent zone. And so on and so forth until you reach the root zone. The root's KSK are hardcoded in the resolver.

Note: the key rollover process is slightly more complicated. Because of resolvers caching data, you might need to keep old records (signatures) for a time.