Changing policy to allow USB drives. Why should I try to stop it? We are currently in the process of allowing USB memory sticks, but with a stricter policy. Some key points in the policy is:

Any confidential data stored on the USB drive has to be encrypted
Always keep your USB drive with you or in a safe place if it contains sensitive data
USB drives which are used in work situation should never be used for any private (non-business) objective.

I've read about Security Threats in this article on wikipedia: Usb_flash_drive#Security_threats, but I am having some trouble in explaining exactly how and why allowing USB sticks is dangerous. Some points I've brought up:

Less attentive to the dangers that could be hiding on an USB drive when it becomes more accepted to use them in the business. People also might not think twice in plugging in an USB they found lying on their desk.
Potential spreading of malware. It is quite common for malware to propagate through USB drives.
Potential exploits to be autorun through USB drive. Example is plugging in an USB drive which is responding as a keyboard. Once it is plugged in it sends the necessary keyboard commands to fetch a file online and run it.

Does anyone have any other arguments in why it's dangerous to use USB drives, and perhaps any suggestions on policy if we need to allow them?

USB drives allow the propagation of data without control from the network firewall -- so any reason why such a firewall was set in the first place is a good reason to ban USB drives.

I do not see how you could enforce a policy of no-private usage. People will use USB drives to transfer private data, if only the latest photographs of their dog, and there is very little you can do to prevent that, as long as USB drives work at all for users. To enforce a security policy, you need to have at least one of the following:

users have no immediate interest in a cheap workaround (e.g. the USB support has been removed from the OS, so plugging a USB drive will make nothing useful to a user);
users understand why the policy was set, and willingly comply (fat chance on that);
technological safeguards are setup (but you may have a hard time making an automated tool which distinguishes business data from private data);
non-compliers are punished with the utmost severity (but if the users themselves do not consider USB drives as potentially harmful, they will not cooperate, thus making USB police operations very expensive).

If you want to allow usage of USB sticks, I would suggest setting it on a dedicated machine, which runs a Unix-like system (thus immune to Windows and MacOS viruses -- for extra security, aim for a confidential setup, e.g. NetBSD on an old PowerPC-based MacIntosh hardware), executes antivirus software automatically, and exports the (verified) USB drive contents through a network protocol (e.g. CIFS, or maybe a simple local HTTP server). At least this will avoid issues with USB devices which act as keyboards. Possibly, this may prompt users to exchange data through the network, removing the need for USB drives in that situation.

As for the dangers of USB devices, you can cite as example the "PSJailbreak" which is the most common PS3-breaking system as of mid-2010 (that was before the discovery of the tremendous blunder of Sony with regards to ECDSA). The PSJailbreak looks like a USB key, but internally acts as a USB hub with four virtual devices, which exploit a buffer overflow in the kernel.


Best practices when forwarding an email or copy / pasting from confidential information sources? I get asked this a lot from older people, or for legal matters. They want to forward an email message they've received to another party, while removing any identifying information from the first party - as well as removing some lines from the body of the original email. The most convenient way of doing this is pressing "forward" on your email client, and then backspacing the stuff you don't want.

What are the implications of doing this, considering:

The work is often being done to a HTML email message , using a WYSIWYG editor (ex. gmail, yahoo, outlook)
Do message headers or other data "follow" when you press forward?

In general, is there a best practice for copy/pasting information from a confidential source (e.g., another email, an internal document) without bringing in additional information accidentally?

I tend to paste everything into a plain-text editor first, because I don't know what an email client does behind the scenes. Is this overly paranoid?

If you can configure your email client to ensure text is the only thing you are copying, you'll be fine, but most commonly used modern mail clients understand macros, formatting, meta-data etc., so cannot be considered safe unless you can fully control that configuration.

To be honest, unless you know exactly how the email client you use handles data (and meta-data) from emails, copy and pasting into a meta-data unaware application (such as notepad) is the safest bet.


Have firewall and VPN already, should I buy a mini router to protect my laptop? I often travel for business and use hotel wifi. I have installed Little Snitch and VPN-Outline for internet security. Should I buy a mini router? Will it keep my computer safer？ Otherwise，with or without a router, there is any difference in internet security. In other words, a simple router will help in which ways?

A small router would help isolate your device from the hotel network, relatedly it would reduce your wireless exposure, assuming you turn Wi-Fi off on your computer as you are using the router.

You may conflict with the hotel network if you misconfigure the router, this may cause them to dislike you and possibly, disconnect your networking.

You may also find that ensuring your computer firewall is properly configured is as effective and less hassle, than carrying a router and peripherals.


Does gpg --digest-algo have any effect when verifying a signature? It seems that --digest-algo is only used when generating signatures and ignored when used with --verify, but I find the documentation unclear:

  --digest-algo name

  Use name as the message digest algorithm. Running the program with the command --version yields a list of supported algorithms. In general, you do not want to use this option as it allows you to violate the OpenPGP standard. --personal-digest-preferences is the safe way to accomplish the same thing.

Considering:

gpg does not throw an error if --digest-algo and --verify are used together.
A message may specify a Hash header, but it is optional...

It suggests that in some obscure situation, the recipient might need to specify --digest-algo when verifying a signature.

Would be nice to have a definitive answer.

A signature is created by first computing a digest of the message and then using the private key to sign this digest. A signature is validated by computing the digest of the message and then validating using the public key that this is the same digest as was signed.

This means, that the same digest algorithms has to be used in creating and validating the signature and thus --digest-algo should have no effect on the signature validation.

  A message may specify a Hash header, but it is optional...

See The Hash header in GPG ASCII armor for what this header is for. In short: it is optional since it is redundant but is used to know up-front which digest algorithm is used in the message signature instead of only after reading the signature. Thus it is helpful when processing huge messages in a streaming way.


what is the difference between a mac and a digital signiture I understand that a MAC algorithm takes a message and a private key as input and hashes them to a value. I understand that senders and receivers often use MACs to authenticate a message and check the integrity of a message. If a sender/receiver successfully computes the same mac, then (1) the receiver has assurance that the sender has the secret key (2) the receiver has assurance that the message was not tampered with in sending (because otherwise it would generate a new mac value). I also understand that digital signatures are somehow different from MACs. But it seems like both verify the sender and authenticity of the message. If you have a successful MAC scheme set up you know that the message (1) is coming from a person with the key (handling authentication) and (2) has not been tampered with (handling tampering). So what do digital signatures do that MACs don't? What's the difference?

In both MAC and digital signature schemes, you have two algorithms:

Generation: given the message m and a key K1, compute the MAC value or signature s.
Verification: given the message m, a key K2 and the MAC value or signature s, verify that they correspond to each other (the MAC value or signature is valid for the message m, using verification key K2)

With a MAC, keys K1 and K2 are identical (or can be trivially recomputed from each other). With a signature, the verification key K2 is mathematically linked with K1 but not identical, and it is unfeasible to recompute K1 from K2 or to generate valid signatures when you only know K2.

Thus, signatures dissociate the generation and verification powers. With a MAC, any entity who can verify a MAC value necessarily has the power to generate MAC values of its own. With signatures, you can make the verification key public, while keeping the generation key private. Signatures are when you want to produce a proof verifiable by third party without having to entrust these third parties with anything.

Application: a CA (like Verisign or Thawte or whatever) issues a certificate to a SSL server. Everybody, and in particular your Web browser, can verify that the certificate issued to the SSL server has indeed been signed by Verisign/Thawte/whatever. But this does not give you the power to issue (sign) certificates yourself, which would appear as if they were issued by Verisign/Thawte/whatever.


Avoid strong password hashing functions aiding a DDoS attempt on oneself While reading this question, it got me to thinking.
Let's say an attacker has some way to make all of their login attempts appear legitimate - enough IP addresses to never reuse them, different valid browser UA strings on each request matching the spread of browsers usually seen, what have you.
Would a strong hashing function that guarantees things like memory or time complexity (for instance, Argon2) not aid a DDoS on a service by way of amplification?
I'm imagining a service that doesn't fail fast on non-existant usernames to avoid leaking information about their existence through timing side channels, or that the attackers have a list of all valid usernames already and is only attempting those.
Would something like requiring CAPTCHA for every attempt completely neuter the problem?  If not, is there a way of shifting some of the work of validating the password on the user's end without revealing the hash or being vulnerable to the user being able to send whatever they like back, thus flipping the amplification around?

Your question is almost a duplicate of the one you referred to. Anyway some possible solutions that come to mind to reduce login DDoS are:

(as you stated) Adding a CAPTCHA for every attempt, keeping in mind that most CAPTCHA can also be broken with a certain probability
(as you stated) Random usernames (not using the email and not making usernames public)
(similarly to what you propose) Making the attack more expensive by first requiring the client to solve an expensive computational challenge which is easy to verify by the server
Delegate authentication to a third party authentication provider capable to withstand (or even prevent) DDoS
Two-factor authentication (or even two password authentication), where the simpler factor is hashed with a faster algorithm (e.g. SHA2) and is only used to allow verification of the other factor
Strong authentication with tokens having high entropy (e.g. QR code scanned by a mobile APP) requiring  less expensive hashing (e.g. SHA2, as BCRYPT would give no advantages)

As you also stated, in case of multi-factor authentication the factors less computationally expensive should be verified first and an appropriate delay should be introduced to not leak which factor failed.


In page Payment script security needs Currently, I'm working in a Fintech StartUp. We have already implemented our payment solution with redirect in a checkout page hosted in our domain (like https://stripe.com/docs/payments/checkout).

Now, we are going to implement a solution that allow payments directly in the merchants page, but in order to maintain PCI complaint also in the merchants page we need to provide a script, that the merchant can insert in their website, where the sensitive data is collected and forwarded to our APIs (like https://stripe.com/docs/payments/accept-a-payment).

I have to write a JavaScript script that enables "in page" merchant payments, but I don't find in any places a list of the security needs.

Checking several PSP that provide the same functionality I find some of security needs:

The script and the form that collect sensitive data must be hosted in the PSP domain and inserted in the merchant webpage with an iFrame.
The ids of inputs on the form that collect Credit card data must be randomly generated.
The merchants website must load the script directly from our domain in order to remain PCI complaint (There is any way to check this point?).
Javascript file must be minified and uglified.

My questions: are there any document that explains all the recommended security needs of this typology of script? Otherwise, is my security list enough? Are there some errors in my list?

Since you are going to use a script in a page (as opposed to redirecting to a payment page maintained by the service provider), you are subject to PCI-DSS A-EP requirements.

JavaScript is not explicitly mentioned there, but the general requirements you need to follow are (cryptographic measures for instance).

EDIT

Beside Conor's relevant comment below, a few comments on some of the
security points you mention in your question

  The script and the form that collect sensitive data must be hosted in
  the PSP domain and inserted in the merchant webpage with an iFrame.

It does not have to be inserted in an IFRAME, it can be injected as a script directly in the page (see for instance Stripe's API)

  The merchants website must load the script directly from our domain in
  order to remain PCI complaint (There is any way to check this point?).

This is their problem, not yours - you just provide the scripts and take responsibility for them.

  Javascript file must be minified and uglified.

This does not add any reliable security (the minification and uglification is done for performance, and maybe some kind of obfuscation which does not hurt but cannot be tagged as "security measure")

Please also note that the JS part of the code is inherently insecure, you must not rely on it for the security of your data (apart some few general points described in OWASP). The security you need mostly to worry about is on the server (backend) side. You should always assume that what you receive from your frontend is insecure.


How do i know if my ubuntu apache version is secure? I am running Ubuntu 16.04 LTS and checking dpkg -l apache2
gives me version 2.4.18-2ubuntu3.9.

How do i know that 2ubuntu3.9 has the latest security patches listed here at https://httpd.apache.org/security/vulnerabilities_24.html ?

I found the following sites:

1)
https://usn.ubuntu.com/releases/ubuntu-16.04-lts/

Nothing here tells me anything about 2ubuntu3.9

2) https://launchpad.net/ubuntu/+source/apache2/2.4.18-2ubuntu3.9

Nothing here tells me if 2ubuntu3.9 is the latest. It only tells me it was published on 2018-07-04. However latest "moderate" CVE on the apache page above is CVE-2018-8011 which is marked as "Update Released: 15th July 2018", so can I assume that this has not been patched yet on my version? Is there a 2ubuntu4.0 where it has been patched? When will it be released?

3) https://people.canonical.com/~ubuntu-security/cve/universe.html

Cant find any of the CVE from the apache page here. For example, CVE-2017-9789 is not in the list.

Question:
Is there any way I can easily see which CVE my Apache 2.4.18-2ubuntu3.9 is vulnerable to?

How do i know that 2ubuntu3.9 has the latest security patches

This is not a simple. Not all vulnerabilities listed on the Apache security page are relevant for the version shipped with Ubuntu. Ubuntu ships version 2.4.18 with backported patches they consider relevant.

The starting point to look what is fixed would be the Changelog and compare it with the list of bugs published by Apache.

But, that a CVE is not found in the Changelog does not mean that the version shipped is vulnerable against this. For example CVE-2018-8011 is considered to only affect Apache 2.4.33 and not the version 2.4.18 shipped with xenial. Similar the information on CVE-2018-1333 and CVE-2018-11763 say that the specific code where the vulnerability is not included in the version shipped with xenial ("not-affected (code not built)").

Thus, in order to know if a specific vulnerability is still a problem with the shipped version you need to dig through the Changelog and if you don't find the CVE there you need to check why it was not fixed, i.e. likely because it did not affect the version as shipped.

  How do i know if my ubuntu apache version is secure?

The basic idea of this question is kind of wrong. That some software is not vulnerable to known CVE does not mean it is secure. If new vulnerabilities get discovered software does not magically gets insecure until the CVE gets fixed: it was insecure before but the newly detected problems were not widely known yet.

There are several factors to look at in order to determine if a software is sufficiently secure for a specific purpose. One is probably the track record of the software: software which is widely used but had only low severity issues in the past is probably more trustworthy compared to software which had lots of serious issues in the past, even though all known issues seem to be fixed know. For example I would definitely not trust Flash even after the latest security patch but just expect that the next issue pops up within a few weeks (it usually does) and that attackers know and already use issues not yet published.

To keep the risk low (and managed) it is also relevant what impact security issues in the software might cause. Limiting potential impact by using the software only for unimportant stuff might limit the risk as does mitigating potential problems by running the software with low privileges, monitoring suspicious activity etc.


Restrict access to web application to selected computers? I am getting a web application designed for the office staff to use in order to automate a process. There are multiple office locations and hence several computers in multiple location. Is it possible to restrict access to the web application to those computers only?

Yes.

And there are lots of different ways to do so. You didn't say how sensitive/valuable the asset you are protecting is - nor how secure the network is; this has some bearing on the level of protection you need to provide for the application.

An obvious solution is to block access by IP address either in the webserver config, the application or on the firewall between the server and network. However this is only going to be effective within a well managed, highly secured network. Spoofing an IP address is easy within a LAN.

But you say that you have multiple locations (but did not specify how the sites are connected). So this is unlikely to be workable in your case.

A better solution would be to use clent certificates. These cannot be spoofed (if configured correctly) but can be copied (it's just a file) unless implemented in a hardware module or at least implemented in a seperated privilege runtime with appropriate permissions.

There are other aproaches, such as one time passwords stored in a suitably secure location or running a VPN on top of your LAN (e.g. ssh, ipsec or openvpn).

None of these should be considered a substitute for user authentication.


Can STARTTLS protect emails between two organisations? There are a few threads on STARTTLS but none seem to provide a clear overview of what STARTTLS can and can not do with respect to encrypting email in transit.

So my question is, can STARTTLS be configured to secure email sent between two organisations, such that the confidentiality of emails as they transit the Internet is maintained?

Where applicable include:

What limitations does STARTTLS have? And whether they can be worked around.
Are there risks STARTTLS is not suitable for?
What dependencies does STARTTLS have on other controls?

I think I already know the answer(s), but I am interested to see what I have not considered.

STARTTLS can help you to provide reliable encryption between two companies, but it will not do it in the default setup:

STARTTLS depends on the availability and the success of the STARTTLS command at the server MTA. Because the SMTP connection first starts without encryption an active man in the middle could simply modify the connection so that it looks like that STARTTLS is not available. The usual configuration of MTA in this cases is to continue without encryption. This means you have to configure your MTA explicitly do only allow encrypted connections for mails to a specific recipient domain.
Most MTA implement STARTTLS as a best effort and not most secure solution. This means they will try to validate the certificate of the peer but continue anyway if the certificate can not be validated. Thus you have to configure your MTA to do strict certificate validation and fail if the certificate is wrong. Note that there are often different settings on how the subject should be validated and you have to pick the right one.
Mail delivery between MTA uses MX records in the DNS. If DNS can be spoofed the sender MTA will connect to the attackers MTA instead and no certificate validation will help because the attacker probably has a valid certificate for his host. Thus you also need to secure the DNS lookup, that is either make sure that you use only DNSSec (which is often not implemented) or that you configure the peers MTA in your explicitly (i.e. don't rely on DNS).
And then there are companies which outsource the mail management, i.e. use custom domains with google mail or similar. In this case the mail will be decrypted already by the third party managing the mail and not by the final target.

As you can see, there are lot of problems and I'm sure that I've missed some. But even the one I mentioned are hard to fix properly. A better way to protect the mail communication between two companies might be to have a VPN. Or use a mail gateway which encrypts the mails on one side with PGP or S/MIME and decrypts the mails on the other side. In this case the actual transport security does not matter much, because the mail itself is encrypted independent of the transport. Such gateways are marketed as secure mail gateway or with similar names.

Even better would be end-to-end communication with PGP or S/MIME from user to user and not only domain to domain. But this is often too hard to manage so that automatic encryption when the mail leaves the company and automatic decryption when it is received are often easier to handle for the users.


Security Concerns with TCP Forwarding Until now I've been setting TCP Forwarding in ssh always blindly to no but searching on the net, I have trouble finding out what the actual security threat is, when allowing it.

The one thing I did find though was that the manpage states, it only helps to turn TCP Forwarding off if users have no shell access. http://joeyh.name/blog/entry/ssh_port_forwarding/ though says, that it's not so important to have no shell access, but no-port-forwarding in authorized_keys.

So, - what is the security threat with allowing TCP Forwarding in SSH and will I get rid of that concern when I add AllowTCPForwarding No to sshd_config or will I additionally  have to restrict the shell access or add the no-port-forwarding option?

When you use an SSH tunnel, as far as the target server is concerned, its client is the SSH server, not the actual client connecting to the SSH tunnel.

For example, if you have an SSH client running on 10.1.1.1, connecting to an SSH server on 10.2.2.2 and establishing a tunnel to 10.3.3.3, when a client (possibly from 10.4.4.4 or anywhere else) connects to the tunnel on the 10.1.1.1 end, it gets access to 10.3.3.3 as if it was coming from 10.2.2.2., not 10.1.1.1 or 10.4.4.4.

This allows such connections to bypass firewall rules regarding the target server that would have allowed connections from the machine running the SSH server, but not further.

This is typically a problem if the SSH server is a gateway between two networks, with public IP address and one private IP address, for example. A firewall rule that would only allow access to certain services within the internal LAN wouldn't catch connections from that SSH server (unless a special case was made for that machine).

The remote connections may come from much further. On the SSH client side, some SSH clients can bind their listening socket to a specific IP address (e.g. localhost), at least to prevent connections from remote machines from that end. However, you rely on the client using these settings properly.

If your users are allowed to make this sort of connections, or if the firewall (and related) rules you use on your network handle the SSH server's IP address specifically to take this into account this, it can be fine. This being said, you may still want to check where the tunnels are established too, you could also get into trouble with other third party servers too otherwise.

If you don't need any of this, disabling this feature would be better.


How can I secure MySQL against bruteforce attacks? I use Fail2ban on a busy Debian-based database server to secure ssh against brute force attacks, but for performance reasons, I don't want to log every connection from the application server (it would be a big resource hog to read every query to log and parse that by Fail2ban - which is written in Python and is quite slow).
So I'm wondering if there are any built-in mechanisms in MySQL to counter brute-force attacks, or some other tricks to bind MySQL to listen only to particular IP addresses?
P.S. There is a similar question here, but as the answer mainly suggests Fail2ban and iptables, I think my question is not in that vein.

The most simple solution would be not to expose MySQL. Usually, MySQL server is accessed only from the same machine, in which case you can set it to listen only on a Unix socket, or on a loopback interface.
If it indeed needs to be accessed from other machines, these are generally just a few ones, in which case you can firewall the port from any host, but those that legitimately need access to it. (Moreover, if all MySQL users are host-restricted, MySQL itself won't allow connecting from hosts different than those).


Is it safe to store VeraCrypt or TrueCrypt container inside RAR - could this method corrupt the file? I need to split my container into smaller files. So plan is this: I create RAR archive and let it split into about 10 smaller archives, no compression and I also add password for extra security. Is this risk-free?

Yes, this is risk free. Not using compression (as you plan to do) helps speed up the process as encrypted data cannot be compressed. However I would suggest you do not use an extra password. Any extra password you need to memorize would be much better put to use extending your VeraCrypt password with it. Otherwise, having multiple layers of encryption allows an attacker to attack one at a time, rather than being limited to attacking it all at once. The only reason you might want to encrypt the archives is if you do not want an attacker to even be able to suspect that an encrypted VeraCrypt container is present. If this isn't part of your threat model, there is no need to use more encryption.

I am curious why you have any  need to split up a VeraCrypt container, though. Obviously in order to use it, you must concatenate the parts. This makes me wonder if you are trying to upload it to a file hosting service which may limit the maximum size of each individual upload. If this is this case, I strongly recommend you do not do this. Hosting any encrypted container that uses XTS mode on a remote server which may be able to see snapshots of the container over time is very insecure.


Avoid cross site scripting in XML namespace We have a legacy application on spring mvc and we have a web service exposed (SOAP protocol) for some reporting client app. This service was tested by a security team and the report indicates that the service is vulnerable to XSS attack. The proof provided in the report indicates that they injected malicious code in the XML namespace as shown below :

<?xml version="1.0" encoding="UTF-8"?>
<Envelope xmlns="http://schemas.xmlsoap.org/soap/envelope/">
    <Body>
        <getReport xmlns="myReport.xsdn9hqu&#x22;&gt;&lt;a xmlns:a=&apos;http://www.w3.org/1999/xhtml&apos;&gt;&lt;a:body onload=&apos;alert(1)&apos;/&gt;&lt;/a&gt;mbr2jk4t5ff">
             <some_info>some value</some_info>
            <some_more_info>some more value</some_more_info>
           <request>
                <someInput>some input data</someInput>
                <someMoreInput>someMoreInput</someMoreInput>
            </request>
        </getReport>
    </Body>
</Envelope>

The app uses apache axis 1.4 jax-rpc to provide the service. In the response the added malicious code from the xml namespace is sent back as shown below:

<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <soapenv:Body>
        <ns1:getReportResponse soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xmlns:ns1="myReport.xsdn9hqu">
            <a xmlns:a='http://www.w3.org/1999/xhtml'>
                <a:body onload='alert(1)'/>
            </a>mbr2jk4t5ff">
            <geReportReturn href="#id0"/>
        </ns1:getReportResponse>
     . . . . .  report details continue

How do I fix this vulnerability? How can I encode/escape the XML header in this case?

I would not consider it XSS vulnerability, as SOAP services are usually called by another service that would not execute anything in the response.  However you could address it by validating the namespace and throwing a more generic error without including any contents from the payload.  Trying to encode it differently is just creating a moving target and not really fixing it.

XSS is only if you can get a person to go to a web site by redirecting their browser so that it does a POST or a GET to another site, and you can inject your own contents in that site that is executable client-side scripting such as JavaScript.


How traceable is ATM and point-of-sale credit card use back to you in practice? A friend said ATM use is traceable easily, while point-of-sale credit card use isn't - this statement  goes against my common sense.

I searched for the the topic and this is what I have found:

Wired: Feds Warrantlessly Tracking Americans’ Credit Cards in Real Time
The Virginian-Pilot: ATM reprogrammed to give out 4 times more money (Via "ATM Hack Scam. Use any ATM card? Can't they trace it back to you?" on Yahoo Answers.)

So, this suggest the opposite is true: POS credit card use is the easiest thing to trace, while ATM is not that traceable.

Any more definitive answer on the subject?

They can always trace an online transaction to a card number if there is a card in the slot, also they can always trace the transaction to the phone line/network connection the ATM/pos terminal uses. Merchant banks are pretty specific in that they log everything they can. Several times usually.


Does referrer header checking offer any real world security improvement? At work we use a central portal that provides basic SSO functionality to other applications. In addition to verifying the SSO data sent, all of our existing in-house applications (used by the public) also check the referrer header to make sure that the user is actually coming from our central portal. However, we just experienced an issue where a JavaScript code change in the central portal caused Internet Explorer to stop forwarding the referrer header, which brought down all the apps that check that header.

My question is whether checking the referrer header provides any real world security improvement over just checking the basic SSO information (encrypted user ID contained in a cookie)? If it doesn't, is there any documentation/research/etc. that I could use to prove this to management?

I should also mention that unfortunately the central portal is a third party app which we don't have much control over ... so basic SSO information in the form of an encrypted cookie and referrer header information is all we have to help secure things.

It will pick off the low hanging fruit, but in general, it is not hard to spoof a header. I would say that if it has caused issues in the past, it is more than likely not worth the risk to your business apps.


Public Key Crypto - sign Bob's name into Alice's message or encrypt Alice's name I was reading Defective Sign & Encrypt in S/MIME,
PKCS#7, MOSS, PEM, PGP, and XML

and in section 5.1  Naming Repairs

  By signing Bob's name into her message, Alice explicitly identifies
  him as her  intended recipient.

or

  she should encrypt her own name along with her message

Is that including in Alice's plaintext the signed Bob's name or the encrypted Alice's name? Does that mean that you can sign or encrypt specific parts of a message?

So in this case, Alice has a plaintext message, signs Bob's name, adds the resulting signature to the plaintext and then signs the whole thing?

Or how does that work with encrypting Alice's name?

she should encrypt her own name along with her message

  Is that including in Alice's plaintext the signed Bob's name or the
  encrypted Alice's name?

This (5.1.2) is discussing the "Encrypt & Sign" format.  In this use case, Alice writes a message to Bob, encrypts it with his key, and then signs the encrypted blob with her key.  If she does not include her name inside the inner Encrypted portion, then Clara could extract the encrypted blob, re-sign it with Clara's key, and then send it to Bob pretending it is from Clara rather than Alice.

  Does that mean that you can sign or encrypt
  specific parts of a message?

Signing and encrypting are separate operations, and usually nested in one way or another.  As for having a message with mixed encrypted/signed and plaintext parts - sure, depending on the message format.  A MIME message can easily contain both.  But that's not really what this section of the document is talking about.

  So in this case, Alice has a plaintext message, signs Bob's name, adds
  the resulting signature to the plaintext and then signs the whole
  thing?

You're conflating two different cases with your quotes; 5.1.1 (Sign & Encrypt) and 5.1.2 (Encrypt & Sign).

In the first case, Sign & Encrypt, because the Signature which identifies Alice is safely ensconced within the outer Encryption layer, Alice does not need to identify herself.  However, to ensure the decrypted message contains the recipient info that would be stripped off at decryption, she does need to include Bob's name.  Alice's signature and Bob's plaintext name, both encrypted with Bob's key, make for a secure message.

In the second case, Encrypt & Sign, because Alice's signature can be stripped off, she needs to ensure that her plaintext name is inside the Encrypted portion.

All in all, the text of 5.1.3 is probably most useful:

  If Alice encloses both names in the message-body, she can avoid having
  to pay attention to cryptographic choices early on, while she's
  formatting her message text. She can send to Bob in [either way]:


Honeypot SSH connection attempts with no interaction I am seeing a lot (>50% of total events) of connection events on a honeypot I have set up but there is no further interaction, no brute force, just a connect then disconnect.

I'm thinking this is just some kind of scan to see if it's really SSH or to make sure it's not using cert based auth but I don't understand why it wouldn't start a brute force.

I've been looking through some of the source code for botnets I have found nothing that would suggest they would only test a connection.

I don't have much experience with actually setting up a botnet so any explanations or source code you might have would be really helpful.

I used to run a few honeypots and that's the typical pattern:

scans seek out valid services
processes bruteforce the services then immediately log out without taking action
attackers log in and perform actions

In many cases, the 3 phases could occur days apart from each other. IPs between the phases would never correlate, and the attackers would log in with the correct credentials the first time.

It was as though there were "scout" robots finding servers, botnets bruteforcing them, then verified credentials sold or distributed to attackers.


Is a pre-set password in an embedded system secure enough? I have a safety-critical embedded device, which sends data updates (in get requests) and pulls settings from a server. The device uses an embedded microcontroller/wifi chipset called the Particle P1; this takes all sent data and encrypts it with AES, sends it to a server owned by the chipset company (which we'll assume for now is secure enough), gets decrypted, and then gets sent over SSL to my server. To ensure that nobody can push false data or settings to the server, every device has both a publicly accessible serial number, and a ~50 character randomly-generated pre-set password corresponding to that serial number. The server looks up the serial number in a database and compares the password given to the one on file before considering any of the data.

Is this sort of permanent access token system secure?

EDIT: According to the microcontroller vendor, the link between the device and them is properly secured with public-key TLS:

  The Particle cloud uses RSA for session key exchange and authentication and then AES for data encryption for all cloud transactions. Each device has its own copy of the Particle cloud public key and its own private key. I don't know of a doc reference but the source code is all on github for anyone to see.

Alright, the main concern here is that an attacker could intercept the traffic between the chipset company and your server.

How does the device know it's talking to the correct server? If I intercepted the traffic between the device and the server and pretended to be the server, would the device happily give me its password?

The "correct" way to do this is to use client-authenticated SSL. This means that instead of a "password", each device gets a unique RSA or ECC keypair, and a corresponding certificate from the server (which is a Certificate Authority in this case). This allows you to use the bi-directional Client-Authenticated TLS Handshake.

There are secure ways to do authentication using a pre-shared secret known to both server and client, but "here's my password, make sure it matches!" is not one of them (at least not without independently solving the "how do I know I'm talking to the correct server?" problem). One way is having both ends MAC the massage with a key derived from the shared secret. Then the other party can compute the same MAC using their copy of the shared secret and make sure they come up with the same MAC. Another way is to use AES in Authenticated Encryption (AE) mode.

... Or as @SEJPM points out, skip the whole "rolling your own" thing and just use one of the Transport Layer Security pre-shared key ciphersuites (TLS-PSK).


On a mobile, does using a password instead of a PIN make encryption stronger? On a mobile, does using a password instead of a PIN make encryption stronger?

What key does the phone use for its encryption? Would it use the PIN itself?

It depends entirely on the phone. But in general, using a strong password is always better than a weak pin.

The phone may use a key derived from the pin for encryption, in which case pssword is much better and honestly quite necessary.

It may use some secure hw chip to store the key and the chip may limit number of attempts. In this case PIN may be enough.

It can also use something else.


Where are private keys stored? May sound like a silly question but where are private keys stored as part of Asymmetric Encryption?

For example say I have a Web Server and I install a 3rd Party SSL certificate from a third party. When installed the certificate is presented to end users to verify the identity of the Web Server and the public key within the certificate is used to encrypt data as part of SSL. Where does the Web Server normally keep the corresponding Private Key to decrypt the data and how is this kept safe? Would they be in "key stores"?

Depends on the web server and the operating system, for example:

The Apache web server on Linux would store these in flat files in a dedicated directory, which is distribution-dependent, e.g. /etc/apache2/ssl. You can choose a custom path in your virtual host definition, so the path/location is more of a convention rather than a standard or a requirement.
Apache Tomcat, for example, uses a key store, which is encrypted using a symmetric key, and typically the specific SSL/TLS configuration file will contain the key store password.
IIS on Windows may use a variety of certificate stores, most of which are physically located in the Windows registry.

As you can tell, the implementation varies from one platform to another - from flat files, through an encrypted database-like file, down to an OS-provided/managed specialized certificate store.

I hope this helps.


How secure is a password protected file? I have a password-protected excel file that stores other personal passwords.

Obviously there have been a number of ways to crack the password.

community.spiceworks.com

Where do you guys store important passwords? For example, if you are managing company IT, you need to remember all sorts of passwords. I keep it in password-protected file on a server.

If I put my password-protected excel onto my usb or cloud, say that they are hacked and attackers obtain the excel file. He or she should be able to easily crack the password? then what would be considered the most secure way to keep the password file?

What version of Excel are you using? Since Office 2007, the encryption used in MS Excel is 128 bit AES with at least a 50,000 interation SHA-1 hash. If you use the built-in encryption with a sufficiently hard password you should not have to worry about offline attacks. How to define "sufficiently hard" will probably change slightly every few years, but if you're really paranoid go with 15 or even 20 characters and then you can sleep well at night.

As for what I do, I used to use a MS Word doc with encryption as described. Now I use a password manager instead. The main difference is the manager uses AES 256 instead of 128, SHA-256 instead of SHA-1 for the hash, and a configurable number of iterations which I set to 5M. I'm still confident that the MS Word doc was extremely secure. The main reason I switched is I like the user interface of the manager better than that of a word document which isn't designed for security once the document is opened.


Generating shared secret key using existing receivers public key and senders private key I have the public key of the receiver, and the private key of the sender. I want to generate a new key by using the receivers public key and senders private key (also known as the signing key) to encrypt a file for this process i.e. utilizing both of the keys at the same time know as a shared secret key.

Could you please tell me how I should generate a shared secret using an existing receivers public key and senders private key?

You don't need to do this; this is already solved by the SSL/TLS handshake.

The SSL/TLS handshake goes a bit further, in that it not only establishes a secret by using both the public and private keys of both parties, but also uses a certificate to establish that the server is who it reports to be - preventing a man-in-the-middle attack.

A quick, more detailed description of the steps involved is here.

But since you tagged the question with "HTTP", I assume you want to send the file via HTTP. Just using HTTPS means you're already using SSL or TLS for key exchange, negotiation of a secret key, and usage of that secret key for encrypting the file while it is in transit. And some protection against MITM in the process.


Does using HTTPS, TLS, S/MIME, SSL e.t.c. protect you from Deep Packet Inspection and 'Big Data' analytics? The title basically covers it. I want to know if using HTTPS, TLS, S/MIME, SSL will protect you from Deep Packet Inspection and Big Data Analytics? (I know that if someone fakes a cert or gets you to install a fake CA or using MITM software they can fool the average user, I want to know if a semi-diligent semi-intelligent IT security person is safe using those technologies to encrypt the data and connections)

Deep packet inspection (DPI) is a term that commonly refers to standard network middle-men, such as the routers at an ISP, examining content at a protocol layer higher than the layer they need to in order to process the packet (thus inspecting "deeper" into the packet than necessary). For example, an IP router may need to only look at the IP layer (layer 3 in the OSI model) of the packet, but if it also inspects the application layer data (layer 5/7) then it is performing deep packet inspection.

HTTPS (referring to the wide suite you mentioned) is an application layer protocol. It will defend against deep packet inspection that reads the content of the application layer, but not against DPI at lower levels of the protocol wrapping. For example, HTTPS will not prevent DPI from looking at the TCP packet and examining the destination port to guess what protocol it is for. But it will prevent the DPI from learning the actual application data payload of the protocol.

Big Data Analysis refers to analysis performed on very large databases of collected data, but how that data is collected has little to do with HTTPS.  HTTPS is only designed to protect data in network transit, when the destination server in the HTTPS protocol reads data, the data is decrypted and HTTPS protection no longer exists. What happens at that point is up to whatever the client and server are using on top of HTTPS. Likely, the server can do pretty much whatever it wants at that point. (In other words, Big Data generally refers to Data At Rest, whereas HTTPS protects Data In Motion. Since they address different stages of the data, it makes sense that protection in one stage won't apply to data when it is moved to a different stage.)


Lowercase 'w' seen in C:\windows application paths from wmic services list In reviewing several Windows 7 computers built from the same image (using wmic services command), I'm seeing most all the Window services paths displayed as C:\windows not C:\Windows. The 'w' is lowercase. For example, the eventlog service is showing as C:\windows\Sytstem32\svchost.exe. No other machines I've ever inspected shows a lowercase 'w'. I know that Windows 7 has a case sensitive flag that can be set in the registry. I checked that and it is not set to case sensitive.

The concern is that if the machine has been hacked and "root-kitted" it would not be returning the true settings, and the display of the lower case 'w' was just a mistake. I don't have the authority to pull the drives and look at them say on a linux box, so I really can't tell what is up.

Has anybody seen the lowercase 'w' as a normal thing? And if so, exactly why is it occuring?

Windows is not case sensitive by default. If the only symptom you have is a lowercase w and nothing else, it's not an issue to be worried about.

You don't need to remove the drive to inspect on a Linux machine. Download any modern Linux iso, create a bootable USB drive on another machine, and boot on the suspect machine.


Disabling android application debug mode as a security practice There's a security practice which says you should not publish your android application with debug mode enabled.
While an attacker can use apktool to decompile your application, enable the debug flag in AndroidManifest.xml and recompile it, how does not publishing your application in debug mode actually help?

Should it be coupled with anti-decompilation techniques to be useful?

What extra information is put in the application in debug mode if any, that you won't have access to when you later decompile and enable debug flag?

This is likely the same reason that you don't want to release a C/C++ program with the -g flags.  Unnecessary symbols are likely stripped away or obfuscated.   The build system might leave out certain security measures that will make debugging the application significantly easier.  Pro-guard build scripts are likely not included in a debug build.

The following are different types of data that can be kept in debug builds depending upon configuration.  Hopefully you can see why these would be helpful to someone looking to reverse engineering your application.

Debug Symbols

Debug symbols are select pieces of information that are stored within the debug binary.  All function names, file names, sometimes even line numbers are included.  This is so that when a program crashes and a debugger is attached all of this information can be included in stack traces.  It allows the programmer to pinpoint the line of code that is causing a bug.   A debug stack trace might look like the following (taken from this answer):

Exception in thread "main" java.lang.NullPointerException
        at com.example.myproject.Book.getTitle(Book.java:16)
        at com.example.myproject.Author.getBookTitles(Author.java:25)
        at com.example.myproject.Bootstrap.main(Bootstrap.java:14)

A program without debug symbols will only know library definitions.  Like the following:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7ffff7fd3700 (LWP 22532)]0x00007fffe10002b4 in ?? ()
(gdb) bt
#0  0x00007fffe10002b4 in ?? ()
#1  0x0000000000000202 in ?? ()
#2  0x00007fffe1000160 in ?? ()
#3  0x00007ffff66bd1a9 in execute_internal_vm_tests () at /home/bionix/Openjdk8/hotspot/src/share/vm/prims/jni.cpp:5128
#4  0x00007ffff7fd2550 in ?? ()
#5  0x00007ffff6b08bf8 in VM_Version::get_cpu_info_wrapper () at /home/bionix/Openjdk8/hotspot/src/cpu/x86/vm/vm_version_x86.cpp:395
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

ProGuard in Android

Within the Android build scripts (Gradle) you'll find references to ProGuard.  ProGuard is used to optimize, reduce binary size, and obfuscate the code.  Because Java can be completely decompiled Android uses ProGuard to obfuscate the code.  Here's an example of code that has been obfuscated with ProGruard:

// Before
btnNew = changeButtonLabel(btnNew, language.getText("new"));
btnOpen = changeButtonLabel(btnOpen, language.getText("open"));

// After
d = a(d, n.a("new"));
e = a(e, n.a("open"));

You can view the full tutorial with links to source code.

From the Android documentation linked above:

  ProGuard is integrated into the Android build system, so you do not
  have to invoke it manually. ProGuard runs only when you build your
  application in release mode, so you do not have to deal with
  obfuscated code when you build your application in debug mode.

ProGuard is technically optional, but when using Android Studio it is enabled by default for Release builds.

Debug Logging

You should always have some mechanism in your code for removing debug messages from your release application.  Debug messages are stored as strings within the binary, and are not obfuscated.  Which means if you have a message like Log.d("Key " + super_secrey_key); a person analyzing the binary will now know where "Key " is referenced.  You've now provided context, and an interesting place to start analyzing.

There are several ways that you can remove debug logs, and one of them is by configuring ProGuard to strip them out for you.  There are also other libraries that you can use, or you can wrap your logging.  Either way it is important to make the distinction between debug and release for your log messages.


PGP Owner Trust Field & Signature Trust Field Distinction I'm reading Cryptography and Network Security Principles and Practices (5th ed, p584) and reading about PGP keyrings, I'm a little confused about the differences between the owner trust field and the signature trust field. I quote:

  In turn, each signature has associated with it a signature trust field that indicates the degree to which this PGP user trusts the signer to certify public keys.

and ...

  An owner trust field is included that indicates the degree to which this public key is trusted to sign other public-key certificates.

The powerpoint slides I'm reading don't seem to make a clear distinction between the two either:

  Signature trust field:
  Measures how far the PGP user trusts the signer to certify public keys. (The key
  legitimacy field for an entry derives from the signature trust fields.)
  Owner trust field:
  Indicates the degree to which this PGP user trusts the key's owner to sign other public-key certificates. PGP doesn't compute this level of trust; the PGP user assigns it. You
  can think of a signature trust field as a cached copy of the owner trust field from
  another entry.

Am I correct in saying that the owner trust field is the extent to which I (the keyring owner) trust the public key entry in the table?

Does the signature trust field get set manually by the user?

If I have a public key entry from Bob, and Charlie and David have signed it, would I have two signature trust entries for that key? - And do I have to set these manually? - What if I don't know David, what would the value be?

Owner and Signature Trust

Signature trust means a user puts trust into the identity of another user. If Alice signs (or certifies, which is the term I will use from now on for signing other's keys) Bob's key, she declares (following whatever rules) she puts trust in his identity. These certifications are usually publicly available on the key servers. You can fetch those certifications (by fetching somebody else's key, you automatically also receive all certifications on that key), but for now they're still useless (unless issued by yourself).

Owner trust is only issued by you, and not shared with others. It defines, whether you put trust in somebody else's capabilities of doing proper certifications (ie., Alice checking Bob's ID carefully).

If you take both kinds of trust together, you can validate other's keys, although you never met somebody. Given you know Alice and certified her key (signature trust), her key is valid (you're sure about who she is). Without issuing owner trust to her, her certification on Bob is not considered for validating Bob's key yet. If you also issue owner trust on Alice's key (thus, trusting her decisions on certifying others), her outgoing certifications are also considered; Bob's key is now also valid.

For more details, have a look at What is the exact meaning of this gpg output regarding trust?.

Your Questions

  Am I correct in saying that the owner trust field is the extent to which I (the keyring owner) trust the public key entry in the table?

Yes -- and no. It is a part of trust as described above; trust into the key owner's ability to correctly issue certifications.

  Does the signature trust field get set manually by the user?

THe other way round: signature trust is issued by anybody and shared on the key servers. Each OpenPGP user has to manually (and on his own) set owner trust.

  If I have a public key entry from Bob, and Charlie and David have signed it, would I have two signature trust entries for that key? - And do I have to set these manually? - What if I don't know David, what would the value be?

If the certifications (signatures) have been uploaded to the key servers, you could fetch them by loading Bob's key from the key servers. So no, you don't need to set them manually, nor should you (if you didn't verify Bob's key). You could issue owner trust, though.

If you don't know David (ie., not certified his key), the value wouldn't change, or in better words: David's certification would not change anything, as you probably did not put owner trust on David's key.


Revoking signing keys: do they still work afterwards? Scenario: I have multiple signing subkeys, each for every portable device (i.e laptop). None of them have private master key (it is deleted following the tips in Alex Cabal's post. One of the devices is stolen, I download the public key from the server (like https://pgp.mit.edu/), revoke the public version with master key and upload the revoked key back to server. Same procedure goes with encryption key.

And now my questions:

Can I revoke the signing subkey using the public key or do I need a copy of a private key as well?
Should I delete the key from my keyring to have a clean list of keys or should I keep the revoked key (and why)?
How can I inform friends/colleagues about it? Do I email every one of them or is there a more massive approach? If they don't receive the information, will they see for example my emails as "TRUSTED Good signature from ..."?

Can I revoke the signing subkey using the public key or do I need a copy of a private key as well?

No, you always need the private primary key for all key management operations (subkeys, user IDs, ... are all bound by signatures of the private primary key). Consider it was possible to do this using the public primary key, everybody would be able to revoke your key (as the public key is -- well, public).

  Should I delete the key from my keyring to have a clean list of keys or should I keep the revoked key (and why)?

Leave it there. The public key will get resynchronized anyway as soon as you update your key from the key servers. And the public key also carries the revocation information.

  How can I inform friends/colleagues about it? Do I email every one of them or is there a more massive approach? If they don't receive the
  information, will they see for example my emails as "TRUSTED Good
  signature from ..."?

"It depends". Some clients will automatically fetch the updated key when they receive the first mail signed with an unknown (sub)key, others won't.

If you're just doing key escrow and exchange keys in advance, consider creating the new key some weeks in advance to allow people fetching them up. I wouldn't bother people when creating new subkeys (especially signing subkeys) without a real revocation reason, they will realize they're missing the new key as soon as they receive a signed message. As you're taking advantage of subkeys, if they trusted your old key, they still trust your new one (trust and validity are assigned to primary keys, subkey validity is derived from the primary key).

If you suspect or are sure your private signing subkey got into the hands of an attacker, I'd indeed go out and mail those I signed/signed me and/or publish this information at relevant places (for example, if you're signing software).


Security concerns of running auto-login script on server-side? I would like to fetch data from a website to do data analysis on a server. Username and password are required for login to the website. Therefore I will need to run an auto-login script on the server.

My questions are:

Is there any security concern about running an auto-login script on the server side?
How can I store usernames and passwords securely?

This is extremely common practice already, think database connections on servers with most keys stored in plain text on the server, there is little way around it.

You just have to prepare your self for automation:

Ensure the connection is only 443 (SSL or what ever port the SSL is on for this service)
if you access the server physically ensure you only have the required ports open to complete the tasks the server requires.
if you have to SSH to the server ensure you use a password and a cert for the connection

it is as the comments say, secure the server and its activities, do not focus on the password, just ensure its not in a publicly touchable file (away from any web servers) and read only for the user who needs to read it with no permissions to anyone else.

The only list of concerns would be this:

automated logins mean automated connections, you need to ensure you are not getting MitM attacked by putting extra security in, its easier to attack an automated connection (no one there to read the warnings!!)
Where, when and who can read that password file.
security of the server and who can access it

dont forget to ensure that all your passwords are randomly generated and stored in an encrypted keychain if you have a cert then 8 random characters will be enough :)


Using HMAC to generate secret keys I am developing a platform that uses several secret keys for several usages: key1 for hashing passwords (using pbkdf2-hmac-sha256), key2 to generate non-repeating unpredictable uuids (using aes-128 and a counter), etc.

Instead of storing different keys, I thought to generate them from a single key, i.e.:

key1 = HMAC(primary_key, "key1");
key2 = HMAC(primary_key, "key2");
...

Is there any critical flaw in doing that? Is this programming pattern common?
Generating the keys separately obviously gives a small advantage that there are no mathematical dependencies between the keys. However, from what I understand even if an attacker finds key1 he will not be able to find primary_key or key2, right?

Thanks

Short answer: yes you are right and you can do this.

To be on the safe side however, you must ensure not to lower the HMAC function security by using it properly and not putting wrong expectation on the function used.

By design HMAC functions expects one parameter to be a secret key, and the other being a message which could be public (you can find more information here and there). This means that the arguments are not be freely interchangeable, the exact order depending on the language used.

A secret key is a key:

Which is composed of computer chosen random characters,
Whose minimum length is the length of the resulting hash,
Which is never known by the remote user, even a part of it,
Which cannot be controlled or influenced in any way by the remote user.

Depending on your actual need and implementation, all parameters you will provide to the HMAC function may not be usable as a secret key:

primary_key might be a service or domain name for which you will need to derive several keys, in which case it might be a public string accessible to the end-user,
keyn (key1, key2, etc.) may also be a predictable string corresponding for instance to the internal service for which the key need to be generated.

Applied to your question, we have then the following possibilities:

None of the parameters can be considered as a truly secure key but one of them is a password or equivalent: if your primary_key is a user provided password (ie. a potentially human generated random string), you can remain safe by using a password dedicated hash function. Such primary_key may be vulnerable to dictionary attacks & co., but this threat will be mitigated by the use of a proper hash function at the expense of the application performance (such hash functions are designed to be slow).
None of the parameters can be considered as a truly secure key and they do not even include a password: an example of such situation would be if primary_key reflects or is deduced from user's provided domain name and keyn contains the name of the service or server (or is deduced from such info) for which the final key will be generated. Then consider your system as flawed, end of story. Your system is wrong and not secure.
One of these parameters can be considered as a secure key: pay attention to pass this parameter through the proper argument where the secret key is expected by the HMAC function. Not doing so may impair the cryptographic strongness of the HMAC function. For instance, let's say that primary_key is a service or domain name, while keyn is a secure key, compared with your question you may need to revert your arguments: key1 = HMAC("secret_key_1", primary_key);, refer to your language documentation in case of doubt,
Both of these parameters can be considered as secure keys: Then you have the highest security you could expect from this scheme, the arguments can be passed in any order without increasing or decreasing the security (the resulting keys will be obviously different but with the same security properties).

As a side note, HMAC RFC also mentions the possibility to truncate the resulting hash to reduce the information available to an attacker who would try to deduce primary_key starting from a hash. The same RFC admits however that while some research "show some analytical advantages of truncating the output of hashed-based MAC functions", "the results in this area are not absolute". As far as your initial keys are secure, I have the personal feeling that you may have more to loose in such truncation due to shorter resulting keys. In all case, this RFC recommends to keep the leftmost part of the resulting hash and to keep at least half of it.


Should a "password reset" link be valid after changing email? Here's the scenario:

Your account has multiple active “password reset” links out in the world. They expire after 24 hours, and after you change your password.

Instead of changing your password, you then change your account email. Should the password reset links still be valid? Is it a security risk to not invalidate them?

I would argue that yes, you should invalidate them. The email change may be because the email account is compromised. And there is no harm in invalidating them, as the user is clearly logged in and can just request another one if they need to.

That being said, it is much more important to send a verification email to the old mail before you allow a change and if the user lost access, send instead an undo link valid for at least 7 days (ideally more). Otherwise, you risk account theft.

Lastly, if you support 2FA, you should not allow resetting both factors using just email.

PS: Also you should not allow changing mail for a period of time after password reset.


How secure are the passwords stored at Google Passwords? It seems Google activated central place for storing app/website passwords which is accessible at https://passwords.google.com/ and all the remembered Chrome passwords are synched there.

In what format (encryption type) or how all the passwords are stored, how it's protected from hackers and how safe/risky is to keep them there? Are they accessible by Google sys admins?

Based on the information which I've found on-line so far, the following statements are true:

Passwords are always encrypted source.
Chrome uses your Google Account to encrypt your synced passwords source.
Whether or not you use a passphrase, your synced data is protected by encryption in transit.
Your Chrome sync passphrase is stored on your computer and will never be sent to Google.

You can decide to encrypt all synced password with a separate sync passphrase instead. If so, you can use Google's cloud to store and sync your data without letting Google read it.

Related:

How secure is Chrome storing a password?
Is saving passwords in Chrome as safe as using LastPass if you leave it signed in?


should I not accept cookies for the sake of anonymity? Let's say I had a Gmail account. Should I just not have a Gmail account, or should I not use their cookies? How bad are the cookies, in of themselves? I obviously wouldn't log into it, with my VPN or Tor. But what do you think of Google's log in cookies?

Cookies are used to retain information between visits to a website. This gives website the ability to remember you between visits. This allows them to provide better service, but also gives them the opportunity to analyze your long-term behavior.

Disabling cookies is a tradeoff between privacy and convenience. You have to decide for yourself if you want to allow website to recognize you immediately when you visit them or if you want to tell them yourself who you are by logging in with username and password.

Keep in mind that there are also ways to handle cookies between the two extremes "allow everywhere" and "reject completely".

Many browsers can be configured to only keep cookies until the browser is closed. This allows web applications which rely on cookies to work properly, but doesn't allow them to track you over longer timespans.
There are browser plugins which give you finer control over which websites are allowed to store cookies and which aren't. That way you can prevent advertisement networks from tracking you, but still allow your favorite discussion forum to set your login cookie.

There is little reason to visit an email service like GMail without logging in, so allowing them to set cookies is merely for your convenience because it means you don't have to enter your username and password everytime you visit them. However, keep in mind that when you share your computer with other people, you might prefer to not use cookies, because when you forget to "log out" manually, other users of the same computer will gain access to your email account just by visiting GMail. When they also use GMail they might not even notice that they are in your account.


Is the Linux kernel vulnerable to LazyFP (CVE-2018-3665)? Recently, a side-channel attack was discovered that exploits lazy FPU state switching to leak the contents of MMX, SSE, and AVX registers. The vulnerability can only be exploited when lazy FPU saves are used, as opposed to eager FPU saves. I am reading conflicting sources as to whether or not the Linux kernel is vulnerable. One source asserts that it is vulnerable. However, there is another resource from 2016 which explains that Linux uses eager FPU switching by default, indicating that it is unaffected. A commit from 2016 shows when eager switching became default.

Is Linux vulnerable, or is it not affected due to the use of eager FPU switching? My understanding is that it is vulnerable only if eagerfpu=off, which is not the default. Is my understanding correct?

To cite the information from Redhat:

  RHEL-7 will automatically default to (safe) “eager” floating point register restore on Sandy Bridge and newer Intel processors. AMD processors are not affected. ... You can mitigate this issue on older processors by booting the kernel with the eagerfpu=on parameter to enable eager FPU restore mode

For Debian it looks like that lazyFP is fixed for anything using a 4.9 kernel or newer. Debian also links to the kernel commit message from 01/2016 where eagerfpu was enabled for all CPU by default.

As for other distributions one need to have a look which kernel is used, which patches are maybe applied and which configuration settings where used. There is simply no "the Linux" but instead lots of distributions which use different kernel versions with different patches and different settings etc.


Router admin password was changed, how did this happen and how to prevent Internet was extremely spotty for about a week. I was on/off cycling the cable model and router almost daily, before I tried to sign into my router (198.162.1.1). When I did I was presented with a message "level_15" access code required or something similar. I hard reset the router and set everything back up with the same passwords I had used before and it was immediately changed again. After another reset, firmware upgrade, and a strong password chosen for the admin, everything is back to normal.

My questions are:

Is this a common hack and why would someone want to do this?
I thought someone would have to been physically close enough to wirelessly access my router. Is it possible to do these things remotely now?
How was the password changed so quickly after the 1st reset?

Edit:

I was trying to access my router at http://198.162.1.1/, instead of http://192.168.1.1/.

My router password was likely never changed, I was just using the wrong address. Now, I'm very curious what this "level_15_access" is at http://198.162.1.1/.

Seeing that you've erroneously typed 198.162.1.1 instead of 192.168.1.1, the level_15_access login window is no surprise.
198.162.1.1 belongs to a Canadian college, and the 198 address is a login screen for something of theirs.


Android Runtime Code Injection I'm doing research for a static analysis tool to help detect malware in Android applications.  I'm wondering if it is possible to perform code injection on Android without using a class loader.  I know it is possible to load byte code at runtime using the Dex class loader, but I'd like to know if its possible to do this without using a class loader.  I've found projects like https://github.com/miktam/Disabler, which use things like AspectJ to add logging and tracing at runtime.  Correct me if I'm wrong but I think this probably uses a class loader somewhere deep down in the AspectJ library.

I'm thinking something more along the lines of overwriting/implementing a method at runtime with arbitrary byte code of a class that is already loaded, so that the next time it is called it performs some malicious/undeclared action from the original source implementation.  Is this possible?  If so how would one go about doing so?

Update: Trying to clarify my question a bit more.

I'm not interested in calling native code directly or using Runtime.exec.  I have already examined those Java API's in my tool.  Let me give a rough code idea of something I was thinking.

public static void main(String[] args){
    hello(); // BENIGN
    evil("hello", getFile("com.blah.MyClass"));
    hello(); // MALWARE, or alternatively since it might not be loaded also BENIGN until next time application is run.
}

public static void hello(){System.out.println("Hi!");}

public static void evil(String methodName, File classFile){
    byte[] evilMethodImplementation = {0x...}; // some crafted byte code to replace the body of a method in a class file
    RandomAccessFile raf = new RandomAccessFile(classFile, "rw");
    raf.seek(findMethodBody(methodName, classFile)); // seek to the body contents of the method
    raf.write(evilMethodImplementation); // overwrite the current implementation with malicious implementation
    raf.close();
}

This is just an idea of something I was considering to see if it was possible.  Basically I want to know if its possibly to do Reflection without using the reflection interfaces as some sort of messy hack that would bypass my detection.

Yes, absolutely, there are other ways to do code injection.  For instance, a malicious app can execute native code directly, and that doesn't require any class loader.

More generally, in the Android security model, the only security boundary is at the process level (not at the JVM level).  So, nothing in Android prevents code injection into a process that you already control.  As the Android docs state, untrusted code cannot be safely isolated within the Dalvik VM.  That's just a fundamental consequence of Android's security architecture.

(As additional examples, you may also be able to invoke Runtime.getRuntime().exec() to execute native code, disable the Java Security Manager, call setAccessible(., true) and then take over the process, exploit vulnerabilities in any of the Java libraries, or use any of a number of other methods.)

(Also, in Java, some security checks are done by the compiler and are not duplicated by the JVM.  Consequently, malicious bytecode can bypass these checks.  These checks include, e.g., access control for inner classes, exception safety, final fields, and others.  I don't know if the same holds for Dalvik as well, but there are many hairy details here that might allow malicious bytecode to attack class libraries.)


truecrypt second encryption of the master and XTS key with a back door password this table was published by (Ubuntu Privacy Remix Team ), in an analysis document, anyway i was quite skeptical.
On file based containers as well as on completely encrypted partitions or drives TrueCrypt applies a header with a size of 64 kilobytes in front of the volume. A second header with identical structure follows for a possible hidden container within the outer container. If there is no hidden container this second header is filled with random values. Moreover, there are two backup headers of the same size and structure at the end of the volume. For system encryption the second header for the hidden volume and the two backup headers are ommited. Also in this case the header has only 512 bytes. In TrueCrypt versions before 6.0 there were no backup headers and the header size was only 512 bytes.
The first 64 bytes of a TrueCrypt header are a salt value selected at random which is stored unencrypted.
From this salt value and the password the key is derived by which the remainder of the
header is encrypted. Owing to these facts a TrueCrypt header just as the following volume can't be
distinguished from random values. Since version 4.2a the format of
TrueCrypt headers changed three times with the versions 5.0, 6.0 and 7.0. The following table
specifies the format of a TrueCrypt header in version 7.0 and 7.0a.

As remarked in this table the Windows version of TrueCrypt 7.0a deviates from the Linux version in that it fills the last 65024 bytes of the header with random values whereas the Linux version fills this with encrypted zero bytes. From the point of view of a security analysis the behavior of the Windows version is problematic. By an analysis of the decrypted header data it can't be distinguished whether these are indeed random values or a second encryption of the master and XTS key with a back door password. From the analysis of the source code we could preclude that this is a back door. For the readability of the source code this duplication of code which does the same thing in slightly different ways was however a great impediment. It certainly must also hamper the maintainability of the code.

its quite of a shame for a backdoor presence to be correct, Ive been using this software for like a year. can any one make a point by "denying" or "approving" the above claims.

You should learn to read further before panicking:

TrueCrypt 7.0a is a highly secure program for encrypting containers based on the current state of
the art in cryptography. We found no back door or security-related mistake in the published source
code except for our attack on keyfiles. If you use this program in a secure environment such as
Ubuntu privacy remix you may assume with high certainty that no one can get access to the data
stored in your containers as long as they are closed, the passwords are really good and the
attacker doesn't apply highly advanced methods below the layer of the operation system, such as
BIOS rootkits, hardware keyloggers or video surveillance.

That's from the conclusion at the end of the document.


How to prove to a 3rd party that some user logged in? Forgive me any mistakes as I am not very knowledgeable in cryptography.

I would like to prove to any 3rd party that a user, with email $x$, accessed my server/database. Only method I can think of is to request the user to sign some message right after logging in. Problems:

The user may not sign the message even though he already logged in.
Not all users use digital signature schemes.

Is there any way to solve problems 1 or 2?

Thanks in advance.

So you say the problem is, that the 3rd party does not trust you.

I don't see a simple solution. Since the 3rd party doesn't trust you, you need a signed confirmation from the user for each data package he has received from the server.

Then also the user should not trust you. The user can expect that you want to blame him in accessing some sensitive data that user actually has not requested. That's why the user (client) should sign each request and the server should include this request into its response.

So far it looks complicated, but not yet much complicated.

Now look at the implementation. For a PKI based signature browser needs access to the client public key. From the pure JavaScript you cannot do that. You would need either some browser add-on to make user key / certificate accessible from JavaScript. Or you need a non-browser client (Java, C#, Python, ...) In case of add-on user again should no trust it and needs at least the full source code of this add-on. In case of non-browser application again user needs a full source code of the client application.

Instead of PKI, you can use some other scheme for authentication, e.g. some hardware key like YubiKey or Titan. But still the solution will be not trivial.

A simpler solution could be following.

On the server side you log any sensitive operations the user has triggered, any data the user has accessed. When the 3rd party requests any information about user activities, you extract information from the log, send it to the user and ask him to confirm (to sign) this part of the log. User signs it; it doesn't need to be in browser, it can be some offline too). You send this signed log to the 3rd party. User has the right to refuse to sign such a log when you ask him. In such case you  have the right to deny user any further access to your server. This scheme would be much easier to implement.


Null byte injection on PHP? Is it possible to perform null byte injection on PHP code?  And, how would vulnerable code look like?  Could you give me some examples, as I noticed that:

<?php

echo $_GET['get'];

Will not make code vulnerable. I want to know, what are possible security flaws in code that can cause this kind of vulnerability, if possible. Any example would be appreciated and useful.

Null byte injection in PHP concerns how null bytes are handled in filesystem operations. If an attacker can inject a null byte into a filepath, the underlying C function will disregard anything after the malicious character. This can be used in order to bypass constraints such as the intended file's extension.

The following example is from php.net:

<?php
$file = $_GET['file']; // "../../etc/passwd\0"
if (file_exists('/home/wwwrun/'.$file.'.php')) {
    // file_exists will return true as the file /home/wwwrun/../../etc/passwd exists
    include '/home/wwwrun/'.$file.'.php';
    // the file /etc/passwd will be included
}
?>

http://www.php.net/manual/en/security.filesystem.nullbytes.php

In this case, the '.php' extension will be ignored during file operations if the user submits a null character at the end of the file parameter. Combined with a directory traversal string, it allows the attacker to "include" arbitrary files that will be disclosed.


Can a (clearweb) website unmask/ identify TOR users? I know a little about the FBI unmasking TOR users (e.g. Freedom Hosting by javascript 0-day exploit) but presumably there are rules limiting what the Feds can do. But could a website trick you - e.g. into downloading an executable file that connects to the internet outside of TOR and gives away your ip address?

For example: Assume the user has sensible settings (Adobe flash player disabled in the TOR browser). Can the website get you to (unwittingly) download a small Flash file that sends back information directly without going through TOR?

But could a website trick you - e.g. into downloading an executable file that connects to the internet outside of TOR and gives away your ip address?

Technically? Of course it could. It looks like that is pretty much exactly what the FBI did in the Playpen case. If you really care, you have to make sure that there is no way for any of your traffic to not go through Tor.

There was actually a DEF CON talk in 2014 that went into this at some length. That's Zoz - Don't Fuck It Up!, which is available on Youtube. The discussion on Tor starts at 21 minutes, and several parts of it are highly relevant to your question:

At about 23 minutes 30 seconds, a real-life example of a traffic correlation attack based on local (in that case wireless) network traffic to Tor nodes corresponding to participating in illegal actions. That kind of attack does not require attacking Tor at all.
At about 24 minutes, the moral of the real-life story being don't fail unsafe with Tor. If you are doing something where you are relying on the anonymization provided by Tor, make certain that if you fail to use Tor then traffic cannot leave your computer or LAN. This includes software other than your web browser.
At about 27 minutes 50 seconds, the presenter starts discussing Tor deanonymization attacks. Bottom line there: even for NSA and GCHQ, at least in 2012, large-scale Tor deanonymization was not possible, but specific cases of Tor deanonymization were possible (that specific claim is made 28 minutes 30 seconds into the video).

However, the bigger question remains: Why on Earth are you downloading and running untrusted software? That's the attack vector in the case you are describing, and the fact that you are doing that over Tor is largely inconsequential. Don't run untrusted software or open untrusted documents on a trusted system.

Especially if you have reason to believe that the government has an interest in you, be extremely vigilant about what you download, install and run on your system. Force all your web traffic to use HTTPS (Tor doesn't protect your "base traffic", nor does a VPN); use NoScript with a restrictive policy; or even turn Javascript off entirely in your browser (there are plugins to make that easy) if you don't absolutely need it. Put your entire computer behind a Tor gateway, such that it cannot communicate with the outside world without going through Tor.


IIS Application - service account permissions My company is looking to install a 3rd party application on our infrastructure and this application will be installed on an IIS Server with a connection to a SQL server. They require an AD service account with the following permissions, some of which look sketchy to me. What would the risk be of giving an account such permissions, given if a malicious actor compromised the account they could do the following:

Full read write permissions to specific application folders - not an issue.
Read and logon to SQL Server - not an issue.
Must be able to start services - ending services would be a worrying, but any risks associated with starting services?
Starting .exe files - again need to investigate why, but I would assume starting .exe files would potentially allow a malicious user to execute malicious .exe files if the service account was comprimised?
Run .bat files - any thoughts?

The only one of those that is even potentially a major risk is starting services, because services run as their own user instead of inheriting the security token of the process that started them. If the service account can launch more-privileged services, especially if any of them take parameters and/or otherwise consume data that the service account can tamper with, then that is a definite risk.

Everything else is just stuff that an attacker (who manages to compromise the application), or the application itself (if it is malicious) could effectively already do. If a malicious actor already controls code running on your machine, there's not really any need to spawn a new process with the same security token (which is what happens when you launch an EXE or BAT file), although it would make post-exploitation easier. Starting services means running code with different permissions, though, and that's potentially enough to break out of a low-privilege service account and take over the whole, ahem, "SYSTEM".

Obviously you shouldn't give your sandboxes any privileges they don't need - for example, Chrome's render processes cannot launch child processes, even though their permissions are so limited it would barely matter - but as long as the access restrictions on the service account are tight enough it's no big deal to be able to launch EXEs (including cmd.exe, which is all that "Run .bat files" actually does) and if the permissions of the service account are too broad, an attacker who gets code execution within the application won't need any other processes.


How to create a time lock encryption I want to encrypt a file such that the decryption will take at least X days on a standard computer. I figure that the best way to do this is to save only a partial key, such that the missing part of the key will take X days to determine by the most efficient technique (brute force or better).

Is there precedent for this type of encryption? Are there any off-the-shelf tools that do it?

The traditional answer is computing 2^(2^x) mod n for a semi-prime n. This has some nice properties:

It's efficient to computer for the challenger, because there is a shortcut when you know the factors of n.
The construction cannot be parallelized. So the attacker needs to compute squarings sequentially, preventing them from speeding up the attack by throwing more resources at it.

But the attacker can still exploit the parallelism within a squaring using custom hardware, giving a considerable speedup compared to standard CPUs.
The number of iterations needed is deterministic. You can't get lucky or unlucky.

LCS35 Time Capsule Crypto-Puzzle by Ronald L. Rivest has the details, including Java code to generate a challenge.

Letting the attacker brute-force a (short) key is not a good time puzzle. It's trivial to parallelize, if you throw twice as much hardware at the problem, you solve it twice as fast. In addition to that, the runtime is random and you can only choose the expectancy value for the required effort (this could be fixed by having a number of separate challenges).


Openstego LSB Plugin I ran the openstego command line below and got the error "No plugin found with name: lsb". I googled for this error and it said "abstract class should be added." I am not good at java but I want to know how to solve it.

root@~/openstego-0.6.1/lib# java -jar openstego.jar extract --algorithm=lsb -p realobama -sf barackobama2.png -xd /home/kst/Desktop/
No plugin found with name: lsb

You can skip --algorithm parameter. Default algorithm is randomlsb. "lsb" is deprecated and not available anymore.


Can authentication in social networks through VPN defeat the purpose of the latter? If a person uses VPN and authenticates herself to some social network through the VPN, doesn't she lose her anonymity for as long as the VPN session is used ? By losing her anonymity, I mean that her real name may be linked to the IP of the VPN and subsequently the IP of the VPN to torrent downloading (for instance).

Is this possible in principle? If yes, are there any workarounds or suggestions ?

EDIT: The title was somewhat deliberately sensational. Of course VPN have other uses besides anonymity, that can't be hurt in the above scenario.

As noted, VPN tunnels permit secure and private communication through untrusted networks. VPN "anonymity" services, fundamentally proxies on sticks, can also provide limited anonymity.

However, using a particular VPN service for authenticated social-network activity irrevocably destroys whatever anonymity it had provided for the user. All usage of that VPN service from the user's ISP-assigned IP address is affected. Getting a new account doesn't help, given linkage via IP address and payment method. To the extent that the VPN provider retains logs, metadata for all prior usage is also deanonymized (even if content is protected via PFS).

If OP wants both "anonymous" and true-name authenticated activity protected by VPNs, she needs to use two different VPN services, and should carefully compartmentalize her activity between them.


Is it safe to save customer information from Stripe? Do we need to be PCI compliant? Following their tutorial, Stripe allows to save customer and charge them later.

But, does one have to be PCI compliant? In their API Reference, it seems they give lot of information to be stored which seems to be a security risk. If someone gets hold of my API key and customer information, can they misuse the information?

Taking advantage of a service provider, like Stripe, to store cardholder data is a way to simplify your PCI requirements. However, with any solution there are trade off and other requirements you must keep based on the solution you choose. Just because you use someone like Stripe doesn't mean you have no PCI compliance requirements. In the case of using a tokenization solution you need to protect the tokens from being exchanged for the represented data. This means, from a PCI perspective, the system storing the tokens shouldn't have the knowledge (meaning API keys and/or API Auth data) or the ability (no direct access to the API, etc.) to exchange the tokens back to card data.

After looking at the API docs from Stripe it appears they are pretty good about not allowing you to retrieve the credit card number from a token or customer. Looking at the official API docs on CARDS and CUSTOMERS, you listed, it shows that the actual card number is NEVER returned when a CUSTOMER or CARD object is retrieved. So the exposure is limited. Someone could still get valuable information about your customers that you don't want them to have. That is why PCI still requires you to protect the tokens as well as API keys as sensitive data and secure them accordingly.

The PCI guide for Tokenization should be pretty helpful and goes into more detail about what I mentioned above.

PCI DSS Tokenization Guidelines


Are there USB flash drives with read-only firmware? A security risk with ordinary flash drives is that they have re-writable (flashble) firmware, which basically lets a hacker replace the operating system of the USB drive with their own.

Are there any USB drives that are guaranteed to be read-only and do not allow their firmware to be re-flashed?

Yes:
https://www.kanguru.com/storage-accessories/kanguru-flashtrust-secure-firmware.shtml

There exist a few other, mostly encrypted devices uses secure firmware, but this is one unencrypted drive that uses secure firmware with signed firmwares.


Why is a networking hub not secure? How can we make it secure? The reason that a hub is not secure nor safe is that it copies the data to all the connected links, so it is enough for the adversary to connect to one of the links (reason 1)? Are there any other reasons?

If a hub is not secure, how can we make it secure? what are alternative secure solutions?

I know switch can choose the intended link, so it is more efficient, and thus it is harder for the adversary to attack. But,  the only concern for a hub's security is the reason 1 (mentioned above)?

This link says switch gives a better efficiency, they are not a replacement for  hubs for security purposes: Hubs, Switches, and Bridges - Flaws and Security Superiority

You can't make a hub secure.  A hub, by definition, is always going to send the traffic everywhere.  The question you link to about switches is true, but a switch is still a necessary first step to adding the security you seek.  In the related question, Thomas Pornin points out that normal switches can be tricked in to sending information to the wrong place, but that is not true of all switches when properly configured.

Features such as VLANs and static routing can be configured to make sure that a router always knows exactly where traffic should go and won't go anywhere else.  It's important to understand the features of your particular router or switch to understand exactly how to configure connections.

You can't make a hub secure because it has no switching logic by definition.  A switch, on it's own, will make a best effort to figure out where to send information, but if it isn't configured with exact information, an attacker may be able to fool it.  A switch configured with exact routing information (at a port level) will obey the routing information and only send the information to the necessary ports.

If you really need to protect traffic and a hub or dynamically configured switch or router is in the network, you can instead just use an encrypted VPN to secure your data over an unsecured link.  At that point it doesn't matter if an attacker can get your data feed as they will be unable to read or alter it.