PCI Penetration Testing - Does the whole infrastructure need to be retested on significant change?

Short version:

PCI documents leave room to support either stance
Your QSA's approval or disapproval trumps anything you think the documents say (as always!)
In practice, I have seen QSAs accept limited-scope pentests when "significant changes" were limited in scope to the environment

Long version:

On the face of it, the wording of the DSS seems absolute; that a complete pentest is required annually and upon significant change:

  11.3 Implement a methodology for penetration testing that includes the following:

  ...

  Includes coverage for the entire CDE perimeter and critical systems
  Includes testing from both inside and outside the network

  ...

  11.3.1 Perform external penetration testing at least annually and after any significant infrastructure or application upgrade or
  modification...

  ...

  11.3.2 Perform internal penetration testing at least annually and after any significant infrastructure or application upgrade or
  modification...

However, when "significant change" is talked about, the 2015 Penetration Testing Guidelines are clear that this is an area where judgement is necessary:

  What is deemed “significant” is highly dependent an entity’s
  risk assessment process and on the configuration of a given
  environment. Because of this variability, a significant change is not
  prescribed by PCI DSS.

If you go back to the 2008 Penetration Testing Guidelines, the equivalent section seems even more receptive to the argument that not all pentest requirements are equal:

  Significance within a highly segmented network where cardholder data
  is clearly isolated from other data and functions is very different
  than significance in a flat network where every person and device can
  potentially access cardholder data. As a security best practice, all
  upgrades and modifications should be penetration-tested to ensure that
  controls assumed to be in place are still working effectively after
  the upgrade or modification.

I think that last sentence can be interpreted to mean that controls not assumed to be impacted by a "significant change" do not need to be retested along with that change.

One of the case studies in the 2015 Penetration Testing Guidelines also supports the idea that the scope of the assessment may vary based upon the judgement of what the subject (and their QSA) consider in scope for the penetration test:

  The web applications for Brand A and Brand B will be completely in
  scope. The web application for Brand C is presumed to be an exact
  copy, exclusive of product information and look and feel. The tester
  will sample the web application for Brand C to verify that the
  applications are the same as Brand B. If it is determined that there
  are material differences between Brand B and Brand C web applications,
  Brand C will be brought fully into scope.

And when it comes to retesting vulnerabilities that were identified in the penetration test, the 2015 Guidelines make it clear that some latitude in test surface is expected:

  The scope of a retest should consider whether any changes occurring as
  a result of remediation identified from the test are classified as
  significant. All changes should be retested; however, whether a
  complete system retest is necessary will be determined by the risk
  assessment of those changes.

So, while nothing explicitly says "You can reasonably limit 'significant change' penetration tests", it is in line with statements that recognize the variability of environments and risk profiles.  As with many things in the PCI DSS, if you can convince your QSA to agree that it is reasonable, then it is accepted.


I emailed someone a picture of a check I wrote for them. What now?

I disagree with @quietsigns answer.  There are other people that could potentially see your email.

For one - email can be sniffed while in transit.  Probably not super likely but still possible.

Second - if the destination email is ever compromised (or is currently compromised) then it's likely that this email will just be sitting there.  If you are really worried about it you could always ask the receiver to delete the email since it contains sensitive information.

While these scenarios might be unlikely, @quietsigns assertion that "The only people who might see the photo of your check are the system admins of the lines and servers your email went through..." is not accurate in my opinion.


This is almost certainly a scam, using the concept of "spam protection" to try to lull you into a false sense of security.

The email is likely one of three four things:

Spammers looking for real (active) email addresses, so they can focus their efforts.
Spammers using you to solve their captchas for them. Pretty sneaky!
A site stuffed with browser exploits, aimed at getting malware onto your box.
Phishing for personal details. Notice that they said the "identification step needs only to be completed once", implying that they're going to ask for personal details.

Each are viable, but I think #2 or #4 are probably most likely.

Either way, just delete them.


Will a search page vulnerable to XSS affect other users?

When you enter something in a search bar and it gets executed, it is called reflected XSS because the payload is reflected from the URL (e.g. https://example.com?search=[javascript code]). If it would be stored and displayed to others later it would be what is called, well, stored XSS.

I read your question to be something along these lines: "Is reflected XSS really that dangerous since it only runs on my computer?"

You are correct that reflected XSS will only run in the browser of the person who visit the link - in this case you. Doing refleced XSS on yourself is a bit pointless, since you only need to hit F12 to fire up a console if you want to run some JavaScript on your own machine.

But now think about what happends if you craft an URL that you fool others to visit (send it in an email, post it on Twitter, post it on a forum, etc). Now the JavaScript will be executed in their browser. You could create a link that will log passwords entered by the user who clicks it or steel that users cookies. That is dangerous stuff.

So while stored XSS is arguably more dangerous than reflected XSS, reflected XSS is still a serious issue that should be fixed promptly if discovered.


S/Key as an alternative to UNIX passwords

For a brief description, see Wikipedia. This is basically a one-time password system: the user does not have a single password, but a long chain of passwords, each password being usable only once. The point is that if a key logger grabs a used password, then the attacker gains nothing because once a password has been used, it no longer grants any further access.

The system is quite nifty: there is an initial secret (W) which is not stored anywhere. From W is produced a chain of passwords, with a hash function h: h(W), then h(h(W)), then h(h(h(W))), and so on. The passwords are used in reverse order, and, at any time, the server stores the last used password, and grants access if the user presents a password which, when hashed, yields the currently stored password.

On the user side, this requires that the list of password is printed on paper, or that the user owns some sort of device which contains the list of password or can regenerate it on demand (the device would store W).

All these passwords are not really "passwords" in that the human user does not choose their contents, and does not remember them. They are "keys" which the user happen to type with his fingers on a keyboard. Human users rarely like the use of one-time passwords.

A generic problem with one-time passwords is that they tend not to work with systems which do password-based encryption of other data elements (typical of Windows systems).


Does ASLR protect against a buffer overflow within a struct?

ASLR never prevents any buffer overflow. A buffer overflow is when the application writes more bytes in a buffer than can possibly fit; putting the buffer at any random address cannot fix that.

What ASLR changes is the consequences of the overflow. A buffer overflow is exploited by an attacker by trying to making the extra bytes spill over some other elements in a controlled way. ASLR makes that more difficult in two ways:

By "moving things around", the field that the attacker tries to overwrite will not necessarily be located at a predictable place beyond the overflowing buffer.
A classic overflow exploit is about overwriting a jump field (return address on the stack, vtable for a C++ object...) so that execution jumps elsewhere; ASLR tries to force a blind jump which is unlikely to go anywhere interesting (for the attacker).

In the case of a struct, ASLR will not separate the two structure fields, because that would be contrary to the C specification, and it would break code. Regardless of ASLR, the variable2 field will always be right after the variable buffer in RAM, so the buffer overflow will predictably overwrite variable2. However, ASLR still moves code chunks between two executions of the application, so overwriting variable2 might not be sufficient to, say, inject arbitrary code.


Using the same password to encrypt and to authenticate other actions

This answer is based on the discussion between Schroeder and wtdmn in the comments.  Yes, the client's private key (corresponding to the client's public key in the client's certificate) will need to be decrypted in order for the client to establish a TLS connection with the server, using the client's certificate.  But, once the client's private key is decrypted, why not use the client's certificate (along with the decrypted client's private key) to authenticate the client?  See https://medium.com/@sevcsik/authentication-using-https-client-certificates-3c9d270e8326 for a good write-up of how authentication using client certificates works.

Then, the PIN to decrypt the client's private key is used only once - to decrypt the private key at the beginning of the process.  So, the flow would be:

run program / enter PIN to decrypt certificate private key / start TLS between c-s / validate certificates etc. / authenticate using client certificate / authentication complete


What is risk of having memcache in public interface?

To what extent a hacker can potentially cause harm to a server? Can
  you please give few examples?

A few examples are XSS and data ex-filtration.

For more information on the XSS scripting exploit, please review: http://niiconsulting.com/checkmate/2013/05/memcache-exploit/

For more information on the data ex-filtration, please review: http://blog.codesherpas.com/on_the_path/2010/08/securing-memcache-in-2-minutes.html

It seems there are two CVE's for MemCache, specifically:

CVE-2010-5276 -
The Memcache module 5.x before 5.x-1.10 and 6.x before 6.x-1.6 for Drupal does not properly handle the $user object in memcache_admin, which might "lead to a role change not being recognized until the user logs in again."

CVE-2010-5275 -
Cross-site scripting (XSS) vulnerability in memcache_admin in the Memcache module 5.x before 5.x-1.10 and 6.x before 6.x-1.6 for Drupal allows remote attackers to inject arbitrary web script or HTML via unspecified vectors.
Keep in mind that there could be more vulnerabilities with MemCache that have not been publicly disclosed.


Can SQL test by using SqlMap tool harm a website?

You could corrupt or destroy all the data on the system.

Never try this on a live system. Clone one or build one in order to test.


People often equate SHA2 as being SHA256...

Do they? While this is not fully true it is not fully wrong: SHA-256 is part of the SHA-2 family which also includes SHA-512 and others. See What is the relationship between “SHA-2” and “SHA-256”

  ... so then would SHA be 160 bit? AKA SHA1?

SHA is originally not SHA-1 but SHA-0. From Wikipedia:Secure Hash Algorithms:

  SHA-0: A retronym applied to the original version of the 160-bit hash function published in 1993 under the name "SHA". It was withdrawn shortly after publication due to an undisclosed "significant flaw" and replaced by the slightly revised version SHA-1.

Despite this SHA-1 is often simply called SHA, like in cipher names like  TLS_RSA_WITH_AES_128_CBC_SHA.

  Does a depreciated SHA1 mean one should consider disabling SCHANNEL\Hashes\SHA?

This setting seems to affect the availability of SHA-1 in older versions of Windows (up to Windows 2003). But not every use of SHA-1 is bad. While it is no longer considered secure enough to be used for signing X.509 certificates used by TLS it is still considered safe to be used as HMAC as used in ciphers like TLS_RSA_WITH_AES_128_CBC_SHA. See Will Google block HMAC-SHA1 along with SHA1 signed certificates?. Thus, disabling SHA-1 in general using this registry key is not recommended (but it is probably recommended to use a newer version of Windows than Windows 2003).


How can I protect my eCommerce site from stolen credit cards?

Normally when using the card with an official payment gateway, a reported, stolen credit card should be marked as unusable. The card will be refused by the gateway.

If you really need advanced authentication before allowing a card to be used by the client, you should verify his identity by making the client send you a copy of his ID card or passport and a recent bill (water, electricity,...) which states his name and address. This address should be the same as on the credit card. Do note that this will make transaction a lot more difficult and cumbersome and make some clients go away.

Also make sure that when performing credit card transactions you are completely PCI-DSS compliant if you have to be. If your business is not PCI compliant there are various measures that the card brands can take, ranging from warnings and monetary fines to revoking your ability to process transactions entirely. More importantly, the PCI DSS allows you to assure your customers that you're protecting their credit card data appropriately. In case of a breach you can also be held legally liable by your customers.


I've never done this myself but it was done by Chris Paget at Defcon in 2010 successfully for an equipment cost of about $1500.  You can find more information on what he did at the following links:

http://www.wired.com/threatlevel/2010/07/intercepting-cell-phone-calls/

http://www.darkreading.com/security/news/226500010/researcher-intercepts-gsm-cell-phones-during-defcon-demo.html

http://www.theregister.co.uk/2010/08/02/gsm_cracking/


Certificate based authentication vs Username and Password authentication

1. Users are dumb

A password is something that fits in the memory of a user, and the user chooses it. Since authentication is about verifying the user physical identity remotely (from the point of view of the verifier), the user behavior is necessarily involved in the process -- however, passwords rely on the part of the user which is most notoriously mediocre at handling security, namely his brain. Users simply do not grasp what password entropy is about. I am not blaming them for that: this is a technical subject, a specialization, which cannot realistically become "common sense" any time soon. On the other hand, security of a physical token is much more "tangible" and average users can become quite good at it. Evolutionists would tell that humans have been positively selected for that for the last million years, because those who could not hold to their flint tools did not survive enough to have offspring.

Hollywood movies can be used as a model of how users think about passwords -- if only because those users go to movies, too. Invariably, the Arch Enemy has a short password and just loves to brag about it and distributes clues whenever he can. And, invariably, a British Secret Agent guesses the password in time to deactivate the fusion bomb which was planted under the Queen's favorite flower bed. Movies project a distorted, exaggerated reality, but they still represent the mental baseline on which average users operate: they envision passwords as providing security through being more "witty" than the attacker. And, invariably, most fail at it.

"Password strength" can be somewhat improved by mandatory rules (at least eight characters, at least two digits, at least one uppercase and one lowercase letter...) but those rules are seen as a burden by the users, and sometimes as an insufferable constraint on their innate freedom -- so the users become to fight the rules, with great creativity, beginning with the traditional writing down of password on a stick-up note. More often than not, password strengthening rules backfire that way.

On the other hand, user certificates imply a storage system, and if that system is a physical device that the user carries around with his house or car keys, then security relies (in part) on how well the average user manages the security of a physical object, and they usually do a good job at it. At least better than when it comes to choosing good password. So that's a big advantage of certificates.

2. Certificates use asymmetric cryptography

The "asymmetry" is about separating roles. With a password, whoever verifies the password knows at some point the password or a password-equivalent data (well, that's not entirely true in the case of PAKE protocols). With user certificates, the certificate is issued by a certification authority, who guarantees the link between a physical identity and a cryptographic public key. The verifier may be a distinct entity, and can verify such a link and use it to authenticate the user, without getting the ability to impersonate the user.

In a nutshell, this is the point of certificates: to separate those who define the user digital identity (i.e. the entity which does the mapping from the physical identity to the computer world) from those who authenticate users.

This opens the road to digital signatures which bring non-repudiation. This particularly interests banks which take financial orders from online customers: they need to authenticate customers (that's money we are talking about, a very serious matter) but they would love to have a convincing trace of the orders -- in the sense of: a judge would be convinced. With mere authentication, the bank gains some assurance that it is talking to the right customer, but it cannot prove it to third parties; the bank could build a fake connection transcript, so it is weaponless against a customer who claims to be framed by the bank itself. Digital signatures are not immediately available even if the user has a certificate; but if the user can use a certificate for authentication then most of the hard work has been done.

Also, passwords are inherently vulnerable to phishing attacks, whereas user certificates are not. Precisely because of asymmetry: the certificate usage never involves revealing any secret data to the peer, so an attacker impersonating the server cannot learn anything of value that way.

3. Certificates are complex

Deploying user certificates is complex, thus expensive:

Issuing and managing certificates is a full can of worm, as any PKI vendor can tell you (and, indeed, I do tell you). Especially the revocation management. PKI is about 5% cryptography and 95% procedures. It can be done, but not cheaply.
User certificates imply that users store their private key in some way, under their "exclusive access". This is done either in software (existing operating systems and/or Web browsers can do that) or using dedicated hardware, but both solutions have their own set of usability issues. The two main problems which will arise are 1) the user loses his key, and 2) an attacker obtains a copy of the key. Software storage makes key loss a plausible issue (at the mercy of a failed hard disk), and sharing the key between several systems (e.g. a desktop computer and an iPad) implies some manual operations which are unlikely to be well protected against attackers. Hardware tokens imply the whole messy business of device drivers, which may be even worse.
A user certificate implies relatively complex mathematical operations on the client side; this is not a problem for even an anemic Pentium II, but you will not be able to use certificates from some Javascript slapped within a generic Web site. Certificate requires active cooperation from client-side software, and said software tends to be, let's say, ergonomically suboptimal in that matter. Average users can normally learn to use client certificates for a HTTPS connection to a Web site, but at the cost of learning how to ignore the occasional warning popup, which makes them much more vulnerable to some attacks (e.g. active attacks where the attacker tries to feed them its own fake server certificate).

On the other hand, password-based authentication is really easy to integrate just about everywhere. It is equally easy to mess up, of course; but at least it does not necessarily involve some incompressible extra costs.

Summary

User certificates allow for a separation of roles which passwords cannot do. They do so at the expense of adding a horde of implementation and deployment issues, which make them expensive. However, passwords remain cheap by fitting in a human mind, which inherently implies low security. Security issues with passwords can be somewhat mitigated by some trickeries (up to an including PAKE protocols) and, most of all, by blaming the user in case of a problem (we know the average user cannot choose a secure password, but any mishap will still be his fault -- that's how banks do it).


How can I know that the CA certificates in my computer have not been spoofed?

Once upon a time, you could check your root certificates against a paper book:
http://www.cl.cam.ac.uk/research/security/Trust-Register/

These days, try to check as many independent sources as possible - for example install different browsers on different operating systems on virtual machines, and see if they agree with each other.

If you are worried specifically about your employer, print out a list of the root CAs at work and take it home and compare it with your home machine. (Or vice versa, bring in a printout from home.) If you work somewhere that isn't allowed, I'm surprised you haven't just been told to accept a new certificate and that you will be monitored anyway.

If you think the NSA have compromised both your work and home, and anyone you ask to burn you a CD-ROM for a clean install might also be an NSA plant, you have bigger problems. (And if you're right to think that, even bigger problems than that.)

Edit: Something I forgot - certificate pinning (draft standard). This will warn you if the certificate used by e.g. http://gmail.com changes in an unexpected way, so may alert you to a MITM attack. A explanation of how it works for Google: https://www.imperialviolet.org/2011/05/04/pinning.html

And DANE. That's not really something you can do, but it's something that may alert you to that sort of attack if it is adopted. See also https://www.imperialviolet.org/2011/06/16/dnssecchrome.html


Alarming Rate of "Sign-Out Errors" in Outlook Account

I am getting this error but only under one condition. I am pointing users to a  URL which skips home realm discovery:

https://login.microsoftonline.com/login.srf?wa=wsignin1.0&whr=**domain.name**

Signing in works perfectly, and after this I'm redirected to the Office Portal, but when I press “Sign Out” on the Office Portal, I get a “Hmm… we’re having trouble signing you out.” error.
This is something to do with the fact that the above URL creates a WS-FED session and Office Portal is then generates an OpenID Connect session. Sign Out requests an OIDC sign-out and interestingly enough also a WS-FED sign-out session with a wa=wsignoutcleanup1.0 parameter, but something most likely does not detect the end of the WS-Fed session, hence the error.


So in building the private key for rsa it will use ssh_host_rsa_key, username, MAC Address, and /dev/random as a seed for my local private key for the user."

No. It is not true. The private key is generated only based some bytes from /dev/random, which are formed into the private key inside OpenSSL.

Host keys are not used, because normal user who generates the keys do not have an access to them. username and hostname are stored only in a comment of the public key (default behavior, but can be changed) and MAC address is not used (at least not in the OpenSSH), as you can find out in the OpenSSH source code.

Not sure how "Debian barely random key gen scandal" is related to this. It was a bug in OpenSSL, which limited the possible keys. It affected OpenSSH, because it is using OpenSSL for crypto operations and random data source.


Is Auth0 Passwordless Authentication secure?

Fundamentally, this sort of authentication is only as strong as the email account the user is using.  However, the same criticism can be levied at any relegated authentication model - OpenID or OAUTH included.  However, I think that this is still well worth it - by leveraging existing services that users value, it means that they are not tempted to use throw-away or repeated/re-used passwords on your site.  You'll be reinforcing the value of those central auth sources (in this case the email), and hopefully that will lead to users using strong authentication in those cases.

Also, authentication is hard to do right - so many smaller sites (and even huge ones) mess it up.  Passing that off, whether via this Auth0 or via more traditional OAuth or OpenID, is a great idea.  I don't see anything fundamentally wrong with the emailed token approach.


Are there any HTTP servers that can detect two cookies with the same name, but issued from different subdomains?

It is impossible for the server to determine where a cookie originated from,  and if an application is designed properly the origin of a cookie should not be a concern.  Based on the Same Origin Policy for cookies:

  www.foo.bar.example.com may set a cookie to be sent to
  *.bar.example.com or *.example.com, but not to *.something.else.example.com or *.com

Using this simple rule the problem of an attacker setting cookie on a related domain can be avoided entirely.


How can a scammer scan your data if you're redirected from their fake website to the legitimate website?

If I understand that comment and question correctly, the scenario is:

There is a legitimate domain, homeaway.com
There is a site registered by a presumably malicious party, homeaway-eu.com
At the time of the question, homeaway-eu was simply a redirect to homeaway.com
You are asking specifically about how opening a browser and going to "homeaway-eu.com" could help an attacker, considering that in doing so, you immediately end up at the legitimate homeaway.com.

You are correct that any information you enter on the legitimate howeaway.com should not be accessible to an attacker. Having a redirect to the legitimate site does not allow any shenigans on data entered on the legitimate site. However:

If in the future an attacker Eve sets up a data entry form on homeaway-eu.com, when then submits the data to homeaway.com, she can collect the data. Since the evil domain submits to the real domain a user might not even notice, especially if the user is accustomed to going to homeaway-eu.com instead of the real site.
As the comment you linked points out, Eve could start sending mail as eve@homeaway-eu.com. A user might not be suspicious since going to howeaway-eu.com goes to the expected site. There is no address spoofing involved so this will basically be impossible to detect. As far as email providers are concerned, Eve has a legitimate domain which she owns, it just happens to be similar (to humans) to a completely different domain. This can aid in social engineering and phishing.
If Eve knows about an exploitable brower bug, she could easily set up a "drive by" attack on a user who visits her site, prior to redirecting to the real site. The user would be none the wiser as they end up on the correct site.
If Eve is only collecting IP addresses for future attacks (or subpoenas, if Eve is working for a government agency, and it turns out the "legitimate" website is questionable itself) then the redirect webpage is all she really needs to accomplish this task, with no further action required.
Perhaps the redirect site reacts to specific IP addresses or ranges, or perhaps it looks for specific tracking cookies, and does something different based on that.

There is probably more I missed. In general, going to an attacker-owned webpage is not a good idea no matter how benign it may appear.


This is a nasty vulnerability.  In short,  it allows a remote attacker to read and/or write to an arbitrary memory address.  So you can't modify a register directly.  Being able to read an arbitrary memory address is very important in modern exploitation because it allows you to read an ASLR'ed memory address.  This is important because when you control the EIP,  you can then point it to the exact memory location of the attacker's shell code.  This vulnerability also bypasses canaries,  its not a buffer overflow, the attacker can overwrite the return address directly on the stack which will become the EIP when a target function returns.


Why mobile phone app sessoins are never timed out?

They may or may not be using token based authorization, and they may or may not be timing out sessions.  The reason they never ask you to log in again is entirely separate, and for convenience.  Users don't want to log in over and over again, and apps that make them cause them to be unhappy, and being unhappy causes them to give the apps bad ratings, and bad ratings make the developers of the apps unhappy, and application developers don't like to be unhappy, so they don't make the users do things that they don't want to do.

So, some ways that apps that do time out session but don't require repeated logins might manage this would be, for instance, storing credentials directly, and using them to obtain a session token each time they need one, (not great) or they may be retrieving a long-lived authentication token on first use that they can store as a surrogate credential, and use that token to retrieve a short-lived session token when the app is used. (better option.)


Capturing traffic on WiFi Network using Wireshark

Not really. Use airodump-ng for that. airodump-ng will provide PCAP-files that can be examined with Wireshark.

[edit] some explanation, because of downvote and comment:

Theoretically, you could put your Wlan card in monitoring mode

sudo ifconfig wlan1 down
sudo iwconfig wlan1 mode monitor

and use both tools to monitor the network. Ideally, you would use an interface that you reserve specifically for this purpose.

In practice though, we often see a factor more packets in the airodump output than in the wireshark output. This is not uncommon: others have reported this as well. Some have suggested that it might be a driver issue, but I have seen this on multiple Wlan devices (with different kernel modules).

So my advice is still: use airodump-ng for that.


Virus checking and cleaning an external hdd

Are you sure tour system doesn't have an application that scan or index new devices? Like a media player that tries to extract metadata from multimedia files.

I would recommend booting from a live CD or live USB in read-only mode, not mounting your partitions, and disconnected from any network. After that load [a VM with] your antivirus, then mount your external drive and check it. However, this will not prevent a rootkit from infecting your BIOS and you will have no guaranty that your antivirus found all the malware. It's still better than nothing.

If you want a bullet proof method to remove your virus from the drive, the only way is to destroy it. Erasing it is not enough, as its firmware could be infected.


How can short-circuit hash equality be exploited?

This answer on crypto.SE outlines the attack Anders points out in the comments. Even if there is a salt it's still best practice to make it a time-safe comparison simply because salts are assumed to be public information, though in practice it seems unlikely it'd be a big issue unless you divulge the salt without also divulging the password hash.

Your assumption about this attack requiring a first pre-image attack on the hash seems logical, but it has a major problem: the pre-image space that matters is the pre-image space of hashed passwords, not of the hash itself (i.e. the preimage of H(p) where p is a password rather than H(d) where d is any data). This is a problem even with a slow hash because that pre-image space can be much smaller, such as trying the 220 most re-used passwords (vs eg 2128 for the hash itself).


Am I weakening symmetric OpenPGP encryption by deploying a custom pre-derivation?

Apart from the fact you'd better not deploy custom crypto code anyway, you're reinventing the wheel. OpenPGP's string-to-key functionality is configurable and can be adjusted to your needs, while not losing compatiblity. I'm not discussing your choices in the number of cycles here, although they seem a little bit harsh. I'd recommend reading At what point does adding more iterations to PBKDF2 provide no extra security? on this topic.

From man gpg:

  --s2k-cipher-algo name

  Use name as the cipher algorithm for symmetric encryption with a passphrase if --personal-cipher-preferences and --cipher-algo are not given.  The default is AES-128.

  --s2k-digest-algo name

  Use name as the digest algorithm used to mangle the passphrases for symmetric encryption.  The default is SHA-1.

  --s2k-mode n

  Selects how passphrases for symmetric encryption are mangled. If n is 0 a plain passphrase (which is in general not recommended) will be used,  a  1  adds  a  salt  (which
  should not be used) to the passphrase and a 3 (the default) iterates the whole process a number of times (see --s2k-count).

  --s2k-count n

  Specify  how  many times the passphrases mangling for symmetric encryption is repeated.  This value may range between 1024 and 65011712 inclusive.  The default is inquired
  from gpg-agent.  Note that not all values in the 1024-65011712 range are legal and if an illegal value is selected, GnuPG will round up to the nearest legal  value.   This
  option is only meaningful if --s2k-mode is set to the default of 3.

To wrap up, following options will have the same effect:

gpg --s2k-mode 3 --s2k-digest-algo SHA512 --s2k-count 10000000 --symmetric

--s2k-mode 3 is GnuPG's default (and only reasonable setting for this option); I did not include --s2k-cipher-algo as this is not relevant for key derivation (and not handled by the "pre-derivation" you described, anyway). Alternatively, you can set this as default in your gpg.conf:

s2k-mode 3
s2k-digest-algo SHA512
s2k-count 10000000

Those options can not only be used for symmetric encryption of messages/files, but are also used for passphrase protection of private keys.


This article at malwarebytes is very informative.

The ransomware uses a small kernel with a built in crypto engine, and when it pretends to run chkdsk it actually encrypts the MFT using a key generated for that machine and sent to the attacker.

The same engine will run the decrypt based on a key given when you pay the attacker.

As the MFT is the reference for every block of every file, without it you can still see all the data if you analyse the drive, but you don't know how it fits together, what block is part of what file etc.

The Salsa20 algorithm works like this:

uint8_t *key = 128_bit_key_generation();
uint8_t *nonce = unique_message_number();
unsigned len = 500;
uint8_t buf[len];

// Position (in bytes) in the stream
uint32_t sindex = 0;

for (sindex = 0; sindex < 5000; sindex += len) {
    // recv 'len' bytes into 'buf'
    s20_crypt(key, S20_KEYLEN_128, nonce, sindex, buf, len);
    // copy 'len' bytes from 'buf' elsewhere
}


Random SYN_SENT connections to Amazon EC2?

I noticed this same phenomenon with my Ubuntu 14.04 machine today (all kinds of connections to EC2 instances such as ec2-52-22-249-100.compute-1.amazonaws.com from Chrome), and on my machine at least, Ghostery and the DuckDuckGo search engine integrated with the omnibar both seemed to call out to EC2. You mention you don't have any extensions installed, what about other search engines?

By disabling Ghostery and closing Chrome completely, waiting a few minutes for the TCP connections all to close, then starting up Chrome, the connections eventually stopped. The instant I checked the box to enable Ghostery, they started back up. For DDG, I noticed it made EC2 connections after performing a search through the omnibar.


Is chrome's prediction service for faster page loading vulnerable to attacks? is it safe to leave it on?

It does not make sense, in terms of providing faster service, for Chrome to pre-fetch all those pages and process all of them before you visit them.

What happens is that the code is fetched and loaded, but not processed. When you click on a link, then the code is processed. This makes the process faster.

So, if there is malicious code on one of those links, it might get pre-fetched but it will not get executed until you click the link.


Linux and Windows Password Security Settings

The authentication systems in Windows AD and Linux are completely different. Windows AD uses Kerberos, which uses various "tokens", "tickets" and keys to establish identity. Linux systems can use Kerberos authentication if there is a Pluggable Authentication Module (PAM) to support it, but more likely they continue to use their native authentication system which is as Scottie H described.

It is, of course, possible for the most part to set the various parameters (password complexity, expiration, etc.) the same in both systems, but finding all the right levers to push and knobs to twist on two disparate systems may be an exercise in futility, and there may be certain combinations of parameters which may be mutually incompatible across the two platforms.

I would also consider that passwords themselves are rapidly outliving their usefulness, and multifactor authentication (MFA) is the secure way to go. However, implementing MFA cross-platform is fraught with the same sorts of incompatibilities unless the infrastructure (e.g. RADIUS for hardware or software token authentication) is carefully chosen with both platforms in mind.


Node.js http-proxy-middleware: secure connection between servers

In your use case if the TLS is good implemented I don't see any problem.

Sure the most secure way is VPN and full ipsec but I don't know the functionality of your app so maybe it's an overkill.

How all security guys says "It depends" how sensible and interesting is your data on wire.

Anyway I suggest to look in a bit in source code of http-proxy-middleware. What when Node.js is in the question I allways look in source code of packages to prevent possible memory leaks and security leaks.

As Node.js user I suggest to use on every project before deploy https://snyk.io/ it's optional but I do it so I can sleep better and full trust I have only in my code :)


Linux log files to back up and review for security

You should back up all files, not just ones you think look important.

Don't back up individual files either. Instead, have your syslog daemon send a copy remotely to your backup server in real time. Most syslog daemons support this, and the good ones even support sending it over an encrypted channel. If that is not supported, you can always set up an encrypted tunnel with stunnel, or transmit it over a VPN's virtual interface to the target. It's easy to do with various sysloggers like rsyslog, journald, or syslog-ng.


Why is password strength often underestimated and uncertain in the context of password hashing?

Password hashing gets a lot of coverage in security guides and there is no good reason for this. Stopping SQL injection and executable file uploads is far more important. I think the reason for so much discussion is because it uses interesting-sounding technologies (like bcrypt) and few authentication libraries do it right by default.

The password storage best practice you mention is not universally agreed on, although it is heavily promoted by users on this site. In particular, using a slow hash algorithm is not usually possible on high traffic sites as the processing load is too great. There's an interesting document here

Password storage is generally invisible to users. Whether you use unsalted MD5 or scrypt, a user won't see any difference. Password strength is highly visible to users, and in particular, it is part of the registration process that most sites want to keep as simple as possible.

Something that is pretty universal is that having more security costs you something. And here's the difference between password storage and strength. Doing stronger password storage costs the site admins - but you can always buy more hardware, etc. Enforcing stronger password complexity costs the site users - and they will go away if they don't like it.

All security choices should be based on an understanding of risk. You don't need the same level of security for Angry Birds as you do for online banking, or indeed for nuclear weapons. In commercial environments, this kind of risk-based thinking is generally not done for defences that only cost the site admins, but it is heavily done for anything that affects the user experience.

For password strength, my advice is:

Low sensitivity - at least 6 characters
Medium sensitivity - Either: at least 8 characters, and a mix of letters, numbers and punctuation) OR at least 16 characters (at the user's option)
High sensitivity - use multi-factor authentication

It doesn't just depend on the sensitivity of the site though. There's a difference between online and offline attacks. A web site password doesn't need to be that strong, because an attacker can only try to guess it online, and you can use a lockout policy to slow these attacks. However, a Truecrypt password can be attacked offline (if the attacker has the drive) - so they need to be much stronger.

Password lockout policies are another important part of doing password authentication well, but they do not get the same coverage as password storage.

The more you look at passwords in detail you realise they are a pretty flawed authentication mechanism. All this best practice advice for making passwords as secure as possible is kind of like trying to re-attach a plane's wing using sticky tape.


What happens if the private key of a Trusted Timestamp Authority is compromised?

If the private key of a Time Stamping Authority (TSA) were to be compromised then any timestamps issued by that TSA would lose verifiability. This would mainly mean that the use of such a timestamp wouldn't be valid in court for proving that a contract was signed on such-and-such date.

  Does it is a single point of failure to all the SSL/TLS certificates?

TLS certificates don't use Time Stamping Authority values.  Public CAs now send certificates to Certificate Transparency logs; but Signed Certificate Timestamp values don't have anything to do with Time Stamping Authorities.

Even for things which were cryptographically timestamped, the person requesting the timestamp can usually request timestamp values from multiple parties. As long as at least one of them had never had a key compromise (or evidence of clock tamper) then their timestamp value would still be considered authoritative... keeping the document considered appropriately timestamped.


Vulnerability scanning: White list pentester or not?

If you are getting your network assessed for the first time I would suggest giving the pentesters complete access.

You will get a report that is comprehensive which would include all the vulnerabilities that exists in your assets.

This will give you the complete understanding to plan upgrading the security of your network.

Moreover, during a pentest, the testers attempt a large number of attacks within a very short time. Please remember that in practice, an attacker might try these attacks slowly, over a longer period of time, and slip beneath the radar. To enable the testers to test efficiently, white-listing the testers is a essential.


Combining dilutes your advantage. This slow-hashing business is about fighting the attacker on equal grounds, your CPU against his CPU; scrypt further equalizes things by optimizing the password hashing for the kind of hardware that you use (a PC) instead of letting the attacker optimize things on his side with non-PC hardware. If you spend half your CPU budget on PBKDF2, than that half is a bit wasted, since the attacker can thoroughly optimize PBKDF2 with a GPU.

See this answer for more analysis on the subject.

The article you quote seems to be of dubious quality. For instance, it badmouths bcrypt on the basis of alleged weaknesses on 3DES -- but bcrypt is not at all about 3DES, and there is no known attack of academic cost "80 bits" on 3DES either. I suggest that you do not trust that article too much.


Does Time-based One Time Password improves security in case of database leak?

Actually, password is what is supposed to protect the user in case your database leaks. If you hash and salt properly, the attacker should not be able to obtain plaintext version of the password (with reasonable password in reasonable time with reasonable resources, if an attacker such as the NSA is after you, don't rely on this. Also, if you know your database leaked or could have leaked, force users to change password to be sure). Your app should not accept the hash as a valid password. So the attacker should not be able to log in even if database is leaked. Note: If you want to hash on client side, check schemes such as SCRAM-SHA256 to protect form this kind of attack.

TOTP on the other hand protects from user password being leaked by the user, or otherwise obtained (brute-force, interception, keylogger) without compromising server.

If you want additional protection in case server is compromised AND password is obtained (for example attacker intercepts login requests and get the password that way), consider either using something like SCRAM to limit the password exposure to the server, or using public-private key pair for login, possibly with hardware token using U2F.


Limiting database lookups by token metadata

This would be what the latest OWASP list calls "Broken Access Control". You are requiring authentication, but not checking that the user has permission to access the resource.

You don't really have any other option but to check that the user has the appropriate permissions. This means after validating the token you will have to read the value of the user id and pass it into the functions that operate on the data.

Depending on your language or framework you also may have a convenient method of accessing the autheticated user id via some other mechanism.

If it slows down the application or increases the load then so be it. The alternative is to leak data by a simple manipulation of the request body or url parameters.

You should also make sure that you protect admin level functions with appropriate claims in the JWT.


Is the TV show "Person of Interest" realistic?

The real question is not if it would be possible to construct a machine which could stop any type of terrorist attack but if you could construct a machine which will stop any attacks without impacting normal live, expected freedom... . If you don't include the second part stopping terrorism is easy already now: kill all people, which of course includes all possible terrorists.

Of course nobody wants this kind of severe side effects. But any technology you use will have some side effects, like tracking the movements of everybody, analyzing everything what you speak and put you in jail in case something you do looks even a bit suspicious.  The question is which side effects are acceptable and which are not. How this question is answered depends on the society, on the (perceived and real) danger of attacks, on the impact of such attacks compared to other problems (like care accidents) etc. In short: it might be possible to have such technology but its side effects of reducing privacy and freedom will be considered too high and most people rather accept some risk.


Privileges separation over parent/children processes on UNIX systems?

In a typical implementation, the child can only ask the parent to perform specific predetermined operations. It does not have a completely free hand.

So for example the parent might have the power to delete any file, but will only accept requests to delete files under a specific root.


how to make socat ignore client certificate?

The problem was the certificate request part. The client application didn't send any certificate and if option verify=0 is added to the socat listener it works fine. verify is set to True by default.


How to transfer a database of usernames and passwords to a friend

What you are asking to do violates some foundational concepts of security, so I am advising against a technical solution.

Credentials are meant to validate a user against that trusted asset. Passing those passwords to a 3rd party breaks that trust (even if you trust the 3rd party, your users do not have that chance). If I was one of your users, I would be very, very angry. What you propose is called a "breach". You are exposing a user's passwords to a 3rd party without their consent.

Even OAuth allows the user to specifically state what service they want to log in on, giving the power to the user.

The best solution is to simply invite the users to create a new account on the 3rd party service, and there are lots of ways to make that streamlined without disclosing your user's passwords. Like sending a pre-filled account creation link for the new site.


Do I need an ASV to come out when going for an SAQ?

Only the external scan requires an ASV:

PCI 3.1 states:

  11.2.2 Perform quarterly external vulnerability scans, via an Approved Scanning Vendor (ASV) approved by the Payment Card Industry Security
  Standards Council (PCI SSC). Perform rescans as needed, until passing
  scans are achieved.

It is only on internal scans where you can run a tool such as Nessus (em mine):

  11.2.1 Perform quarterly internal vulnerability scans and rescans as needed, until all “high-risk” vulnerabilities (as identified in
  Requirement 6.1) are resolved. Scans must be performed by qualified
  personnel.

  verify that the scan was performed by a qualified internal resource(s)
  or qualified external third party, and if applicable, organizational
  independence of the tester exists (not required to be a QSA or ASV)

The external test does not require anyone "coming out". You can simply use an automated service such as Hacker Guardian which will satisfy the scan being done by an ASV.


Encrypting files securely using user supplied password

My observations are as follows:

Storing the value of l is pointless. You should store n instead. You should be aware that PBKDF2 doesn't produce different sequences for different values of l, but rather extends the sequence longer.
Generating 1024 bytes for k and 512 bytes for P seems odd, since AES accepts no larger than a 256-bit (32 byte) key.
In step 5 of the encryption, you say that k is encrypted using AES-CBC, but do not mention how the IV is selected. This isn't hugely important here, since k won't have duplicate blocks, but it's good practice to use the cipher mode properly.
In step 5 of the decryption, you again mention AES-CBC without specifying the IV. This is critical - improperly selecting the IV may completely break the system.
You provide no authenticity on the file or the stored metadata. This is actually important, because AES-CBC is malleable (i.e. ciphertext can be modified in ways that affect the plaintext, without needing to know the key) and your construction could be particularly susceptible.

Your general construction is actually alright, but it's missing the details that separate a secure construction from a weak one.

Here's how I'd do it:

let p be the user's password.
let kd (data key) be a random 128-bit value.
let s (salt) be a random be a random 128-bit value.
let c be the iteration count, e.g. 1,000,000.
let km (master key) and ka (authenticity key) be computed as two 16 byte (128-bit) halves of PBKDF2(p, s, c, 32), i.e. PBKDF2 of the user password and salt, with the defined iteration count, and an output length of 32 bytes.
let k'd (encrypted data key) be computed as AES(kd, km), using 128-bit AES in ECB mode.
let IV be the initialisation vector for use when encrypting the file data.
let Q (metadata) be the concatenated values s | c | k'd | IV.
let aQ be the authenticity record for Q, defined as H(Q, ka), where H is a cryptographic hash function in a HMAC construction, e.g. HMAC-SHA256.
store Q and aQ in the file header.

Since 128-bit keys are being used, and AES has a block size of 128 bits, only one block need be encrypted when computing k'd and therefore AES in ECB mode is safe; the additional complexity of using CBC or another mode is unnecessary.

Providing an authenticity record for the metadata helps prevent an attacker from "tweaking" the parameters needed to decrypt the file. Most critically, it provides authenticity of the IV, which is a prime target for modification as xor'ing it with a value will result in the first block of plaintext also being xor'ed with that value upon decryption. This property is known as malleability. For partially known (e.g. structured) plaintexts, this can have devastating effects.

You should be able to extrapolate the rest of the file encryption and decryption process from here. One addition I would make is to compute a HMAC hash of the encrypted data, then store that in the header, to ensure authenticity of the encrypted data.


Why are lengthy passwords stronger than complex ones?

Simply because exponential growth is much faster than polynomial growth.

For a password  which has a fixed length n, where the number of characters in your character set (x) is variable will give you a complexity of xn.

This is a polynomial function, and grows accordingly as x is increased.

On the other hand, fixing the character set to n and keeping the number of characters x variable gives you exponential growth nx. This increases much faster as x is increases. (Compare the derivateves for reasonable values of x and n if you wish)

Basically, for reasonable values of x and n, increasing x is much more effective in increasing complexity in the second case.

This is why the strength checkers say that it is secure.

However, using dictionary words does open it wide for dictionary attacks, which can be less secure. Try to use a few random strings in there as well.


Does the BitTorrent protocol expose my home IP address, even over VPN/Tor?

The answer to #2 depends a little bit on your VPN provider and how the routing is configured. VPNs that you subscribe to for privacy should hide your IP properly.

The easiest answer is found by performing a test. Do a google search for "bittorrent ip leak" and you'll find results for tests that provide you with your IP address when using a BitTorrent client.

For #3, the answer depends a bit too. It's worth noting that in 2010 the Tor project itself doesn't recommend using Tor for BitTorrent: https://blog.torproject.org/bittorrent-over-tor-isnt-good-idea. It's possible that your BitTorrent client may ignore your proxy settings, for example. I'd recommend to test this by performing a similar test as in #2.


In Logjam attack, the client presents a list of cipher suites (includes some strong cipher and EXPORT cipher as well). A Man-in-the-Middle attack will change this request such that highest grade cipher in the request becomes the EXPORT grade cipher.

The server doesn't want to reject this request (it could be an eCommerce website and server don't want to lose business), so the shared secret is derived using export grade cipher suite which can be broken if that prime group is sieved using GNFS.

Check out this video, it's a long one but from the authors of Logjam
https://www.youtube.com/watch?v=mS8gm-_rJgM


What are the benefits and drawbacks of emailing a user a login token/link?

If you're relying on the email address to verify the original user's identity, whether for login or password reset, then a compromise of the email account means a compromise of the website's account. Therefore, I don't see any elevated security risk in this login scheme. In fact, this is essentially like using a third party authentication service. Think, logging in to StackExchange using your GMail account.

Combining this login scheme with good security practice such as using HTTPS, avoiding injection vulnerabilities, etc. can makes it on par with a password-based login scheme. The only advantage I see here is that the user will now have to remember a smaller number of passwords, that's it. The obvious disadvantage is, of course, the inconvenience of having to go to my inbox, open, the message, and click the link every time I have to login to that website.

If you're planning to use this, I highly recommend having a fallback option to allow the user to login with his password in case he doesn't have access to his email account for any reason.


Can we predict the technology used from the URL?

There are many books that talk about using this type of info gathering and vulnerability testing, but it is under the heading of 'HTTP Headers'. Because web servers are usually configured to 'prettify' URLs, much of the info you list is usually contained in the header of the http request.

For the specifics of your question:

cgi-bin means they use cgi scripts
bv60.dll means they are likely using Windows as the server
BV_EngineID is an internal variable and not helpful unless you can track that variable to a certain known application

But, all of this information can be 'faked' by the server, and all this info and more can be discovered using web server scanners and passive analyzers.

So, it is important to use URLs for info gathering, but anything found needs to be verified, and there are better ways to discover the relevant information.


Can I use something other than AES 128 to store my PSCredential?

Yes you can use up to AES 256 as mentioned here.

  ConvertFrom-SecureString and ConvertTo-SecureString have two
  parameters that you can use to change the default behavior.  These
  parameters are –SecureKey and –Key.  The –SecureKey parameter takes a
  SecureString object and the –Key parameter, a byte array (Byte[])

  You use –SecureKey with a SecureString memory object that encrypt and
  decrypt the other SecureString.  This does not really help us in our
  goal of storing secure passwords and accessing them through
  automation.  You would need a SecureString object built, either by
  unencrypting another string using another option, or by having someone
  type the SecureString interactively.   The first does not solve the
  problem of it being secured, the second does not solve the automation
  problem.

  The –Key parameter allows you to use a 128-bit (16-byte), 192-bit
  (24-byte), or 256-bit (32-byte) key and uses the Advanced Encryption
  System (AES) cipher, also known as the Rijndael cipher, to
  encrypt/decrypt the SecureString.  It is symmetric encryption so you
  need to provide the same key for encryption as you do when you decrypt
  the encrypted string back to the SecureString.  One way to do this is
  to embed the key in each script file.  Not surprising, this not
  recommended and results in security not much more secure than just
  storing the password in plain text in the script.  It also makes it
  difficult to change the key or password which should due frequently
  using this method.  A better choice is to store the key in a separate
  file from the script and encrypted password.


Torrent sites on the onion network being served over http

Tor is a (multi layer) encrypted tunnel. If the endpoint server (here PirateBay) is an Onion server (the URL ends by *.onion), Server 1 see an encrypted response. The Tor software on the client machine decrypt it into plain HTTP.
Server 1, 2 and 3 can alter the encrypted data, but without knowing its content. Also, this data will be rejected by the Tor client because it will detect a corruption.
If the endpoint server is a classical web server (with a URL like piratebay.org), then Server 1 can see the plaintext data of the requests and alter them.


What the vulnerability scanner tried is to add a condition that is either true for all rows ('1'='1', tautology, added with 10590' AND '1'='1) or false for each row ('1'='0', contradiction, added with 10590' AND '1'='1). If you don’t get a different result for these, it’s probably not vulnerable.

However, that the user_id values 10590 and 10590' AND '1'='1 gives you different results is probably because there is no user with the ID 10590' AND '1'='1.


The Mifare Plus product line was specifically designed as a solution to the well known Mifare Classic vulnerabilities. As far as I know there are currently no published exploits against this new generation of cards.


To answer your question, I need to cover the full description of how a new process created.

There's a great description of this in Chapter 5 of Windows Internals 6th Edition Part 1 (ch. 5 being available freely online on the Microsoft website) which explains exactly how all of this works.

I'll paraphrase an overview of what's said in the book, as copying it verbatim would probably have some copyright issues.

The PE loader is exposed by a set of user APIs in kernel32.dll, under the CreateProcess family. There are different APIs for doing different things, e.g. running a process under an alternative security context.

Here's how it works:

The user-mode API validates the input parameters, and converts them to their system (native) counterparts.
It then opens the executable file and loads it into memory.
Creates the executive process object in the kernel. This involves populating the EPROCESS structure and registering the process in various lists.
Creates the main thread of the process (stack, execution context, thread object)
Performs subsystem-specific initialisation - e.g. CLR init for .NET applications.
Start the main thread (unless it was created with the suspended flag set)
Load the appropriate DLLs in the context of the process.

Most of this is done at the kernel level, using the appropriate Ps-prefixed native functions. The full set of steps involved is rather complex (in fact, it takes up 15 full pages in the book) and involves a lot of different actions depending on the susbsystem used.

The tricky part with your question is that the "loader" isn't really something that gets control flow. The instant you call CreateProcess, you're technically running the loader.  However, the kernel part of the loader begins when ntdll!NtCreateUserProcess transitions into kernel-mode. If we're really strict about it, we might say that the first part of the loader is PspAllocateProcess, since that's what allocates the initial structures.


Short answer: Yes, change it.

As long as you can ensure that the attacker is not able to break into your WiFi (using WPA2 is good beginning) and is also not able to get access by other ways (e.g. over VPN, weak WPA2 password, plugging a cable into your switch, malware on your devices, ...), theoretically there is no need to change the password.

However, since you probably can not ensure these requirements, you certainly should change the password. So that in the case the attacker is able to break into your network, he can not damage that much.


You're looking at a version 4 signature packet.

From RFC 4880:

5.2.3.  Version 4 Signature Packet Format

   The body of a version 4 Signature packet contains:

     - One-octet version number (4).

     - One-octet signature type.

     - One-octet public-key algorithm.

     - One-octet hash algorithm.

     - Two-octet scalar octet count for following hashed subpacket data.
       Note that this is the length in octets of all of the hashed
       subpackets; a pointer incremented by this number will skip over
       the hashed subpackets.

     - Hashed subpacket data set (zero or more subpackets).

     - Two-octet scalar octet count for the following unhashed subpacket
       data.  Note that this is the length in octets of all of the
       unhashed subpackets; a pointer incremented by this number will
       skip over the unhashed subpackets.

     - Unhashed subpacket data set (zero or more subpackets).

     - Two-octet field holding the left 16 bits of the signed hash
       value.

     - One or more multiprecision integers comprising the signature.
       This portion is algorithm specific, as described above.

Above it says:

   Algorithm-Specific Fields for RSA signatures:

     - multiprecision integer (MPI) of RSA signature value m**d mod n.

So what you're seeing is indeed the integer denoting the RSA signature (which naturally can't be larger than your key that is the RSA modulus).


Use-case for decentralized identifiers (DIDs) with unique identities for each relationship

One answer (which was cross-posted to the W3C DID WG Issues page where this question was also cross-posted): There is always some correlation risk when an individual entity uses the same identifier for themselves, for interactions with multiple other entities, or even for multiple interactions with one other entity. Multiple strategies are used to minimize that risk in the universe of DIDs, but it still exists. It increases when some of the other entities merge, as in the business world, or when a governmental entity takes and combines the records of the other entities, as in some repressive regimes.
If the individual entity mints a new DID, for each interaction with an external entity, or for each external entity they interact with, potentially using multiple DID schemes along the way, that individual is adding another layer (or more) to the correlation mitigation strategies.
It is desirable for everything to be visible, in the universes of some entities. It is desirable for less, down to as close to nothing as possible, to be visible, in the universes of other entities. We cannot make the determination of what is best for all entities, but we can offer a range of options such that each entity can, with some effort, make their own determination -- which may change, as time goes on.
As to "replacing your FAX number", as @ThoriumBR suggests -- sure, you can give each external entity the same FAX number, or you can give each external entity a different FAX number, at (hopefully) minimal if ay additional cost, all of which reach you, as if they were the same number, but without providing the correlation detail discussed above.
Perhaps that helps?


To make a system like this work you're going to need to either store the users e-mail in plain text somewhere, or store it in encrypted format and then store the key for that in plain text somewhere.

It's inescapable that in an automated system sometimes somewhere the server has to be able to decrypt the data and send it.

If you're interested in "high security" options, you could look at storing the users information in encrypted format on disk and then make use of an HSM to handle the decryption in a more secure manner than just having the key on disk.


Why do examples show creating a CSR from a private key?

A CSR contains the public key as you correctly stated. But it is also signed by the private key as the proof that you actually own the public key in the CSR. This means that both the private key and public key is needed, i.e. the full key pair as generated by openssl genrsa.


how common is it for an antivirus program to give false positive?

... Often antivirus programs trigger a false alarm that a certain file is corrupted or infected. My question is that how common is that

There are detailed tests at https://www.av-comparatives.org/testmethod/false-alarm-tests/.

The results differ between vendors and time but on average can be said that the higher the detection rate (true positive) the higher will be the more false alarms will be triggered (false positive). This is because only parts of the malware is detected by clear signatures, the rest is detected by heuristics which will never be perfect.

These heuristics (or machine learning models) are tuned by the vendor for some specific balance between false positive and false negatives rate. False positives will confuse the user. If there are too much the user will disable the detection completely. False negatives (malware not detected) on the other hand will have a serious security impact too. And models or heuristics can usually be tuned how much false positives and negatives they produce - only the less false negatives they produce (i.e. the more malware they detect) the more false positives they will also produce (i.e. the more innocent files will be detected as malware).

  ...  and if it is too common, can we really rely on them.

There is no true yes or no. If you mean with "rely on them" that you blindly believe the results then no. If you mean  with "rely on them" that the AV results are true in most cases then then yes.  You are not totally safe from malware if you install an AV (or use the existing AV built into Windows) but the average user is usually much safer than without an AV.

  ... Along with that, how easy it is to corrupt antivirus.

Not trivial but possible for a determined attacker with enough knowledge and time. In the past there were several cases of AV being vulnerable to code execution attacks, often due to errors in parsing (deliberately corrupted) files. This was especially bad since many of these AV did there analysis as system user. Bypassing AV instead by hiding the malware so that the AV cannot properly see it, is much easier though.


Is there an easy way to generate all variations around a password?

I had a similar issue a while ago and I considered doing a bruteforce attack on the system, I got all the way to creating my own file to base the attack from and realised that I'd just have to end up typing out possibly hundreds of different variations of the same password, you might as well just manually type them out as it would save time...

Or just accept the loss and reset like I did.


Why are certain languages chosen for security application development over others?

Reason for high level languages:
Let's say you are writing a program that is written that executes under the attackers machine which may send an attack against a remote machine or whatever. There is no point writing in in low level language is it requires more time to manage. So, you may as well write it in high-level language which uses bytecode language such as .NET or Java etc so it's cross-platform and easy to manage and scalability.

Reason for low level languages or native code:
Let's say you are writing some form of pentest code to execute under the victims machine you ideally want less dependencies so it will likely to execute under more machines. If we used high-level language such as Java then we need all victims to have Java VM installed.

If we are talking about Windows platform then other reasons for native code would be exploiting internal windows is much harder to do under bytecode languages. Bytecode only executes under ring 3 where as native languages such as assembly, C and C++ you can write drivers to execute at lower rings.

So, summary just depends on what your coding.


When writing a malware, you should make as few assumptions as possible on the libraries existing on the target (victim) machine. As the sources you show in comment are for Windows, all you can safely assume is that the functions for WINAPI calls will be available, because any additional dependency on redistributable bits for any C or C++ system may be present or not: many Window machines have no installed development tools, and they only have the libraries (DLL) that were required by other software.

That means that to be able to use functions from the C++ (or even C) library, the developper should statically link the used standard library resulting in a heavy application, when a malware should be tiny in order not to sched light on it because of its size.

That's a possible reason why the developpers of Zeus make an intensive usage of WINAPI calls and avoid calls to the C standard library, not speaking of the C++ one which would add a new layer and some overhead in size.


Is it reasonable to store encrypted TOTP keys + authentication credentials on a single device (for end-user)?

Since you mention that you use smartcard features of your Yubikey to store the PGP encryption key necessary to access the pass database, I would say that it is okay to keep TOTP shared secrets in pass alongside other password data. TOTP is a mechanism to ensure 2-factor authentication, so as long as you require the Yubikey to decrypt them, you are still using 2 factors (yubikey = something you have, the PIN = something you know).

There is an important caveat here, though -- there is a lot more application sandboxing happening on modern Android phones than there is on a modern Linux workstation. Anyone who can execute code on your workstation (as your user) will likely be able to grab those TOTP secrets from RAM or by waiting till you insert the yubikey and decrypting them directly once they know the PIN. On the other hand, the storage and memory belonging to a TOTP application on your phone will be generally better isolated from other applications you're using, so it would require a root-level compromise before an attacker can access the secrets stored in a TOTP app.

If that is an acceptable trade-off for you, then you can put those shared TOTP secrets into pass. If not, then you should stick with keeping them on the smartphone.


Can I be MITMed when accessing an HTTPS website from my own device through a third-party network?

Yes. This is why you should use a VPN if you're working on an untrusted network and connect to a trusted network.


I would recommend using a wiki to store the policies, you then get versioning, etc. You can also create templates which include the document control information you need to evidence such as the change date, approval date, effective date, etc. You could probably get away with a lightweight wiki, but if you have SharePoint or KnowledgeTree those might be the way to go. Semantic Media Wiki might also be a good choice. The wiki route is also good because you can embed keywors and tags, such as the applicable PCI requirements which makes it much easier to track individual policies and cross reference.

If we look at the PCI Scoring Guidance, we see that 12.6.2 says

  12.6.2 Verify that the security awareness
  program requires personnel to
  acknowledge, in writing or electronically, at
  least annually that they have read and
  understand the information security policy

Always consult with your own QSA, but if you have a small enough group, you can probably combine this somehow with your annual training in 12.6.1; do a training session with a sign-in sheet and another column for policy sign-off.

If you use outlook, you can use the voting button functionality to collect responses, but you would probably be best served implementing some type of survey web-app that allows you to build survey questions. You could be extra rigorous and test them on what they read, but your basics would be a name field, a checkbox, and maybe an additional field for initials for a digital sign-off. If you use SharePoint, again this can be used to collect surveys.

I don't have any familiarity, but I did a quick search and came up with these:

policyIQ (commerical policy management software)
Power DMS - Policy Workflow (another commercial solution)


In which country can you host a service which honors privacy?

Realistically none.  That's the point of cryptography.  If the government asks, then most (effectively all) companies are going to comply if sufficiently legally threatened.  Cryptography makes it so that the information isn't accessible even if hardware is seized, but you have to be ready to pay the consequences of not cooperating in unlocking it.


Website Certificate Revocation check - Big deal?

Revocation is the only method by which a certificate authority may propagate the information that a private key has been compromised. It is, in fact, a damage containment system: in the unfortunate event of a private key being stolen, the revocation system will make sure that nobody trusts the corresponding certificate more than one week or so after the theft is noticed and reported. If a client does not check revocation status, or bypasses it (as you are proposing to do), then this "one week" delay is extended to the expiration date of the certificate, which can be years away.

By definition, not checking revocation (or ignoring a failure to check revocation) weakens the system, so it cannot be said that it is "safe". But maybe it is not utterly risky. In practice, risks of connecting to a fake Web site are low, because stolen credit card numbers are not worth a lot, and running a fake Web site that successfully emulates a real airline reservation system is a lot of work; hackers who could steal the private key would probably not do that. But that's your decision to take, not mine.

If your browser could not ascertain the revocation status, then chances are that you cannot do it yourself either. However, it may be interesting to know what exactly has happened. Normally, each certificate in the chain contains a URL to the location of the relevant CRL (in a CRL Distribution Points extension). Maybe some of these Web sites are currently unreachable; maybe the CRL they host are out of date, thus revealing a technical glitch on the CA side.

(From my machine, right now, the British Airways certificate looks fine, including revocation status, so chances are that the glitch was temporary.)


Displaying list of registered users on a website

If login names can be guessed or inferred by the display names, then it may allow password guessing attacks to take place.

It is low risk, but if it's not needed for any purpose then it should be removed.


Oooh, that's a tricky one.

Theoretically, the nextUpdate field is meant to be a (future) date at which a new, updated version of the CRL should be made available. The idea is that if you have a cached CRL, then there is no point trying to download a new one before that date.

In "true X.509" each relying party (a "relying party" is "some system which tries to validate a certificate") is supposed to have its own policy with regards to how old a CRL can become before becoming "too old". Yet a RP cannot guess when a new CRL will be available for all possible CA; we use certificates precisely because a RP does not know all possible CA in advance. Hence the nextUpdate field which conveys information about the CA update policy.

In practice, though, everybody took nextUpdate as a CRL expiry date. So the nextUpdate field means "don't bother download a new CRL before date T", all implementations of X.509 certificate validation consider it to mean "don't use this CRL beyond date T". That's not the same concept. "True X.509" does not handle CRL expiration at all, since every RP is supposed to apply its own policy, but that does not work in the Real World: existing CA, both root and non-root, don't have coherent enough CRL update policies to make a RP-local policy workable. E.g. some CA will update CRL only once per week, or even less than that, especially for offline CA; while others publish new CRL every hour.

Since everybody uses nextUpdate as a CRL expiration date, the CA have adapted and also fill that field with these semantics. Microsoft has also defined an extension called "Next CRL Publish" (1.3.6.1.4.1.311.21.4) to convey the information about the scheduled next CRL publication date, i.e. the historical role of nextUpdate (this is a Microsoft-specific extension, I doubt anybody else uses it).

A common strategy for CA is to use some overlap: for instance, they publish one CRL every 24 hours, and the nextUpdate field is set to thisUpdate + 36 hours. That way, the new CRL is available 12 hours before the previous one "expires". Most clients will bother downloading a new CRL only if the one they have in their cache has its nextUpdate "in the past". Some clients (notably Windows) will download the new CRL some time before the nextUpdate if they have some good indication that a new CRL is indeed available, thus making the pre-fetch worth the effort (e.g. because there is a "Next CRL Publish" extension).


Should OAuth2 proprietary client authorization prompt a confirmation window?

If OAuth2 sever and clients are provided by company X and the user can see this, a consent question is not necessary.  Such clients are also called first-party clients.
For all clients consent could be given only on first use and is then remembered by the oauth2 server. This way consent is requested only once per client and not for each subsequent authorization.


Should I keep all UUIDv4 generated oAuth2 Bearer Tokens in my database to prevent an attack?

If you are generating version 4 UUIDs using a cryptographically secure RNG, the probability of a previously issued token matching a currently valid token is exactly the same as the probability of any random token created by the attacker matching a current token.

This means that an attacker with previous tokens has no advantage over any other attacker, and you do not need to keep expired tokens in the database.

Focus instead on ensuring you're using a really secure RNG, preferably sourced from a physical source of randomness.

A more useful reason to keep expired UUIDs is to detect problems with the RNG. If you ever get a repeated UUID, it is possible that there is a bug in your random number generation, similar to the Debian OpenSSL bug (DSA-1571-1).


No, you cannot prove to someone else, that logs on your system have not been tampered with. Clearly, if you own that given system, you can do whatever you like with it, including the manipulation of all files.

In the end it's a question of trust. Therefore that third party would have to define, what they would require to trust your data.
A possible solution for them could be to deploy a third party system between your server and the internet, so that they can observe the network traffic themselves.

There are however tools, that regularly check file integrity, but those usually aim for more or less static file contents like config files and are probably not applicable for log files. Still, if they would do the job, they would still run on your system and do not change the scope of trust, the third party would have to accept.


MySQL AES Encryption - Is it good idea to store 3rd Party Auth Tokens using AES Encryption?

Yes, it's a wise idea, but I'd recommend doing encryption in the application code and not in MySQL, because AES functions in MySQL are using ECB block mode, which is discouraged from being used in cryptographic systems.

Read more at:
https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation#Electronic_codebook_.28ECB.29

To increase security, you could perform encryption/decryption in a HSM (hardware security module) or create a poor man's version of it with software. That way, the cryptographic material (e.g., master key) is more difficult to access.


What are the risks of having a password policy on a domain that is not configured at all

I take it from your question you have a brand new Active Directory domain that has been set up with default password policy.  Presumably you also have default account lockout policy as well.

By default, passwords have an expiration of 42 days, a minimum length of 7, and must meet password complexity rules (e.g. cannot contain the user name, must contain any 3 of uppercase, lowercase, digit, special character, or symbol). These rules don't seem terrible, so leaving them at their defaults doesn't present an intolerable risk.

However, account lockout policy by default is disabled. This opens up your domain to brute force attacks, since a user can try as many passwords as they want for as long as they want. At a minimum you should turn this on, even to a somewhat high number (e.g. 20).


(I speak here more generically than in the specific case of OpenBSD.)

X11 needs some direct access to the underlying hardware, something which requires some extra privileges which are not given to just any process (such privileges can be used to mess with memory transfers, e.g. between system memory and hard disks). So there must be some root-or-equivalent involved at some point. However, once the said privileges have been granted, nothing says that the process which runs the X server must keep on being root. Of course, if a non-root-but-with-hardware-access X server gets subverted, it still may gain, theoretically, strong access to the machine through DMA manipulations, but this does not look easy at all.

(Also, there can be totally unprivileged X11 servers which use a framebuffer interface, although this tends not to be very compatible with support for accelerated graphics.)


An open port is an attack surface that can be exploited.  Reduce the number of open ports as much as possible. If a service isn't required to be accessed by the open internet,  then don't expose it.


How dependable can data encryption be without re-entry of password on startup?

The real questions here is: How much of a barrier can be placed against WHAT attacker?  If the system doesn't need a password at boot,  then if an attacker has physical access then it is trivial to bypass.  That is quite literary not a security measure and an attack like the cold boot attack probably isn't required.

So what about MS-SQL?   Well this encryption system is preventing a REMOTE ATTACKER  possibly with a sql injection flaw access to the sensitive data.   Keep in mind if the attacker has a flaw like SQL Injeciton,  then the attacker SHOULD NOT have full access to the disk,  unless of course you have a web app using an unrestricted account like sa,  which would be a much bigger problem.

Moving just the key to another machine doesn't really help, if the compromised machine can access the key, then the attacker can access the key.  What can help is creating a sensitive information store.  So in this model a web application has two databases.  One database for storage of not very sensitive information, and another database just for the storage of encrypted data.   The encrypted database is made to be the most restrictive,  it is only accessed by a white list of machines and the number of queries against this machine is kept to the bare minimum.   The chances of a sql injection flaw against this database is much lower.


Hide real IP (and possibly location) while live streaming

Unless you want to break into a neighbor's service and mask yourself via their IP address (which is a criminal act), you need to bridge your traffic via something that changes the IP address for you by process of address translation.

That is usually attained 1) behind a home/corporate router or 2) at the expense of a free/commercial VPN. You may rent a VPS of your own too. Warp (1.1.1.1) and other options do almost the same.

The problem with VPN of any kind is that it takes a longer path to the destination. In addition, overhead of the tunneling may increase delay, jitter and drops in video streaming. You can only hope for the best.

So my suggestion is solution #1. Go to office, or use your neighbor's with their permission of course.

Update: if #1 is not an option, try renting a fast VPS or VPN service in a foreign country en route to destination sites (US in this case)


Does git commit hash prove the history until that point?

Not against sophisticated agents with lots of resources.  SHA-1 (the hash used in git) is not considered cryptographically secure these days against collision attacks.  With published methods for a full collision is estimated to cost about ~$100,000 in EC2 compute time.  This is why SHA-1 SSL certificates are considered insecure.

If you ignore the possibility of SHA-1 collision attacks, if you hand someone a commit hash (and later give them access to the repository), they can use that commit hash to verify the following information (which was hashed together in a custom format to create the hash):

the full sha1 hash of the current tree (the tree is essentially a file listing of a commit with file names pointing to sha-1 hashes of the data in files)
the full sha1 hash of the parent commit(s) (multiple in case of merge)
The name and email of the author and committer,
The time stamp of the commit (according to the committer's local computer)
The commit message

So if you email a person with a specific commit hash 43c5ab273a7c897dfd8cad9cef829b3a657f8491 at a certain time, they can later verify that commit was made pointing to specific tree (4c883b33dbb987e46c211f6dad52b91b208661b4) with a parent commit of cef37643eb57177ac9e4e1f3d0178bc67b381c8e.  The timestamp and author/committer information will also be included, but this shouldn't be trusted as being accurate.  E.g., anyone can tell their local instance of git they are whatever name/email they want and push it to a  bitbucket repository they control.

Note, so if someone wants to verify that you had a repository a certain way last month, you can easily go back and edit history and create a new commit (with a new hash) that shows you had the repository that way at that time.  However, if you had given them a hash to the commit of the state of the repository at that time, this would not be possible (without going through the trouble of generating hash collisions).


Vendor Mutual SSL required on behalf of different organisations

What type of certificate is required

A certificate suitable for authentication as a client. As for the exact requirements which CA's are trusted by abc.gov check the documentation you got from abc.gov.

  how would it work given that the domain names will not match

Client certificates are usually not checked against domain names since there is usually not a specific domain associated with the client. There is no standard on what the subject should contain so you would need to check again the provided documentation what is expected. One option would for example the email address of the client.

  Would IT staff from service providers conclude that this practice is unsafe?

I assume they would. Giving somebody a client certificate so that he can impersonate the client is similar to giving somebody the username and password, i.e. abandoning any control what can be done by impersonating the client. Therefore it is usually forbidden by various security guidelines. And I doubt that abc.gov will like that practice too.


Are computers on same network as honeypot safe?

I would most certainly segment any would-be honeypots from the rest of your network. Truth be told I would be very careful about implementing something like this unless you know exactly what you're doing.

If you're planning on trying something like this I would recommend (at a minimum)

Create a different subnet / VLAN and put the honeypot on that.
Ensure proper firewall rules are in place that prevent forwarding of any traffic from the honepot network (in essence, a DMZ) to your primary network.
Create firewall rules that prevent administration of your networking device from that subnet
Use strong passwords on the rest of your network devices
Regularly monitor the honeypot and the rest of your network devices and monitor for compromise.


Is revealing login name of macOS into internet a security risk?

The revealed username
would only be a real security problem if this MacOS computer is directly exposed to the Internet with remote accessible services like SSH, where the username could be used. The username alone would most likely be used for brute force attacks.

The brute force attack would not be that effective, if you have a strong password (and possibly Fail2Ban). However, people often have weaker passwords on their personal computers as they need to type it frequently.
Username information is only useful for brute force attacks if the intruder also knows the IP address of his target.

Other parts of the PATH may, however, reveal something more directly usable. Say you have e.g.  /Users/username/public_html/path/to/known/vulnerable.php that could be directly exploited without brute forcing any passwords.

Then, there's all the possible privacy issues, but as you send this information voluntarily, you are probably  already aware of those.


Does TLS (Transport Layer Security) protect against deliberate tampering or accidental corruption?

It depends on where the data was changed and all you mentioned outcomes are possible. TLS messages has some public scructure. For example, TLS record:

and if its structure is broken, then entire message is considered broken. This doesn't necessarily say if encrypted data was additionally tampered.

If only ciphertext was tampered so entire structure remains valid, it may result in decryption failure. If payload is tampered and was successfully decrypted, then signature validation will fail.

If MAC field is tampered, then it will result in signature validation failure. MAC protects only payload and is used only when payload is successfully decrypted.

Either way, tampering will be detected, only detection reason will be different depending on what exactly was tampered. RFC 5246 defines a set of messages:

enum {
   close_notify(0),
   unexpected_message(10),
   bad_record_mac(20),
   decryption_failed_RESERVED(21),
   record_overflow(22),
   decompression_failure(30),
   handshake_failure(40),
   no_certificate_RESERVED(41),
   bad_certificate(42),
   unsupported_certificate(43),
   certificate_revoked(44),
   certificate_expired(45),
   certificate_unknown(46),
   illegal_parameter(47),
   unknown_ca(48),
   access_denied(49),
   decode_error(50),
   decrypt_error(51),
   export_restriction_RESERVED(60),
   protocol_version(70),
   insufficient_security(71),
   internal_error(80),
   user_canceled(90),
   no_renegotiation(100),
   unsupported_extension(110),           /* new */
   (255)
} AlertDescription;


What are the security implications of adding an Intermediate Certificate into the Trusted Root Store in Windows?

There is no issue with adding an intermediate.
In general it's not needed since a proper certificate chain is included by the server, so having only the roots makes things much simpler.
In a case such as yours (with misbehaving clients or servers) adding the intermediate is a reasonable solution. The intermediate will have a shorter lifetime than the root, and as long as your libraries do proper revocation checks there should be no issues (but that applies regardless). It's just a bit tedious and manual.


Understanding what bot was used for a Botnet attack

The "IRC, HTTP or P2P" categorization of a botnet is about how the worker machines obtain their orders from the control centre. HTTP-based botnets connect to a control site whose URL they know; this is not very discrete in the long run. In particular, since this attack is assumed to be about hijacking servers to build a bigger botnet, each successfully infected server will be given a way to contact the control centre -- in the case of a main URL, the URL will be in it.

Since some big names are currently trying to understand the attack, it seems reasonable to suppose that they already set up some honeypot virtual machines, to observe the infection and observe the result. As a consequence, if the botnet is HTTP-based, they already know the villain's server address, and Special Forces / Spetnasz / SAS / Légion Étrangère are on their way to explain to him the true meaning of pain.

This does not appear to happen right now, so I suppose that the botnet is more protected than that, and uses a decentralized method of communication. This is what spy networks, terrorist organizations and resistance forces have done for many decades. "IRC" and "P2P" are two variants of that principle. In an IRC-based botnet, the network of cooperating IRC servers acts as an involuntary (but often complacent) transport medium; "P2P" will be used to qualify botnets who simply skip that crude piece of old technology and send their packets all alone. In a properly managed botnet, each infected host would know the addresses of only a few other hosts: its cell, and some hosts in adjacent cells.

My bet would go on P2P, but that's just a gut feeling.