How can I prevent my kids from bypassing my computer restrictions?

This issue has come up on a couple SE forums already, so most of this is going to just be echoing my existing answers.

How can I prevent someone from accessing a Windows XP system via boot disk?

How to secure my Windows 7 PC?

A couple of fairly major issues exist here, which are really working against you:

Unless there's something you haven't mentioned, your son probably has relatively unrestricted physical access (in terms of actual security) to your system.  I'll cover some mitigations you can put in place below.
It seems your son is lacking a certain respect for you and/or your rules regarding computer usage.  If you'd like assistance with this, I'd point you to the Parenting Stack Exchange.

Regarding physical access to the computer:

As security compromises of a PC go, physical access is perhaps by far the worst kind.  Once an attacker (in this case, your son) literally has their hands on your computer, most other security methods in place are easily circumvented.  That said, here's what you can do to prevent or hinder these attacks from affecting your system.

Use strong passwords.  Make them 15 characters long at minimum, and use all four character types (lowercase letters, uppercase letters, numbers, non-alphanumerics).  Avoid using any dictionary words in any part of the password.  You should also avoid using anything that would be common knowledge, like a pet or friend's name or someone's sports jersey number - this especially applies when the threat is coming from a family member, who would have intimate knowledge of such things that are dear to you.   Lastly, do not write it down!  This will help better secure any resources that are password-protected, although physical access to the system can bypass most password protections that do not use encryption.  For protection against physical access, also see item 4.
Encrypt the hard drive.  This will prevent any attacker from reading or manipulating the system files when booting into their own environment.  This is the only measure that will generally survive an attack involving physical access to the system.  Also, see item 1.  While this will help ensure your data is not read or modified, it cannot prevent use of the system via boot disc (like your son is using) or attempts to intentionally destroy the data.  See items 3 & 4 for that.
Lock down the BIOS and Boot Order.  Set the system to only boot to the system drive, and set an Administrator password on the BIOS so that this cannot be changed.  Optionally, you can also configure the BIOS to require a password at boot-time regardless of what boot media (CD, Hard Drive, Flash Drive, etc.) is going to be used.  Also, see item 1.  This will prevent your son from booting from a LiveCD, but it is reliant upon physical security to prevent bypass.  See item 4, regarding this.
Physically secure the system case.  If possible, lock the system's chassis with a padlock and/or place it in a secured cabinet.  A chassis lock will hinder efforts to clear the BIOS password by using jumpers on the motherboard, and efforts to remove the hard drive for loading into another system.  A secured cabinet will do that, and also hinder any attempts at plugging in or loading alternative boot media.  More generally, you could also just lock the room the computer is in.  For ideal security, and if you're really paranoid, do all of the above.  This really should be at the core of your solution.  Without this, your BIOS password can be easily bypassed and your son could boot from whatever disc he likes.  At that point your data, if encrypted, may still be safe from being read or modified but it could still be destroyed either intentionally or accidentally.

Also, for the first part of your question:

  Can this damage my computer or corrupt my files? (I have lots of pictures)

Using a boot disk generally does not pose any inherent risks to your system's integrity.  However, at this point your data is at the mercy of whomever is at the keyboard.  If the system can be booted from removable media, whole-disk encryption may protect the data from being read or modified but it cannot protect the hard drive from being completely wiped if the attacker intends to do so.

Your best defenses here would be to follow the steps above as far as they are practical for you, and make sure it is understood that your rules will be strictly enforced with stiff penalties.


How are the packets transferred between a website and the computer that's using a VPN?

A VPN is just another connection. Your computer makes a connection to the VPN server, and the VPN server makes a connection to the website you want to access.

From the website point of view, your VPN server is making the request. If you are using a popular VPN server, that means that your request and a vast number of another requests will appear to come from that single IP address.

The VPN client usually creates a network interface with a private network range, and add a default route pointing to that interface. As soon as your browser sends the request, the packets will go to that interface and will be intercepted by the VPN client, encrypted, encapsulated and sent to the VPN Server using your default internet connection.

On the VPN server, the packets coming from the VPN client will be processed, decrypted, and the server will establish a connection to the webserver you wanted to contact, changing the TCP source to point at him, not at you. As soon as the webserver sends the response, the same process will occur: the server will encrypt and encapsulate the response, send to you, your VPN client will decrypt the packet and send the result to your browser.

  And what protocols are used?

The protocol used by the VPN does not matter much. The main issue is how secure is the encryption of the traffic. PPTP and L2TP are not considered very secure. OpenVPN can be very secure, depending on the configuration options. IpSec can be very secure too.

The protocol used will depend on the VPN server type you are using. If you are using OpenVPN, the protocol will be TLS encapsulated on TCP or UDP. PPTP will use a GRE tunnel over TCP. IpSec will encrypt the IP packet.


Given you have referenced Github, I will assume this related to some type of As an open source project, a note to oss-sec is a good idea. This will bring it to the attention of most upstream distributors.

You do not need to subscribe to post to oss-sec, but you should note carefully the etiquette/content guidelines in the link above. A rummage through the archives should point you in the right direction, this one is a recent posting (from the list maintainer) the form of which you could usefully copy:
 http://seclists.org/oss-sec/2015/q3/61

The NIST National Vulnerability Database is driven by CVE data and should be updated in the near future, they don't suggest how long it might take though. The NVD FAQ also has some useful details, including contact procedures for missing or incorrect entries. I'd suggest giving it at least two weeks (based on empirical evidence) after you post to oss-sec before following up though, the CVE people tend to be busy.


Should password hashes be encrypted or HMACed?

Encryption, or a deterministic MAC, may offer you an extra gain of security on the off-chance that the attacker could grab the database of hashed-and-encrypted passwords but not the encryption/MAC key (which the same server must necessarily know to do his job). Some people call that "pepper" (as a pun with the notion of "salt" -- IT security people are a bunch of joyous fellows). See this previous question on the subject.

Since the scenario is rather restrictive, and using a key implies dealing with key management issues, I would recommend not to bother.


Does the use or the implementation of PDCA or Deming cycle in the Information Security Management System mandatory?

Taken from the book, CyberWar, CyberTerror, CyberCrime and CyberActivism, 2nd Edition

  ISO/IEC 27003 (the ISMS default-suggested by ISO 27001), provides
  practical guidance for implementing a security management system based
  on ISO/IEC 27001:2005 by introducing a comprehensive methodology of
  applying the PDCA cycle to cybersecurity. This standard describes how
  to establish, implement, execute, observe, analyze, maintain, and
  improve an organization’s cybersecurity program. Although ISO
  27001:2013 dropped the PDCA concept in the revision, it still has
  value as a decision-making aid.

A better book is Enterprise Cybersecurity: How to Build a Successful Cyberdefense Program Against Advanced Threats. This book is great because you can use it to integrate to current-running reality. If you must comply with, or obtain, official ISO 27001 certification and you must use ISO 27002/27003 as the ISMS prescriptions -- go ahead with those plans. However, it may be worth the effort to map towards this second book.

In Enterprise Cybersecurity, the frameworks are touched on in Chapter 13, including the introduction of the book's own Enterprise Cybersecurity Architecture framework, a comparative to the other frameworks, such as ISC2's CBK, ISO 27000 series, NIST SP800-53R4, et al -- which also mentions additional coverage in Appendix B. If you can get an Information Security Management program aligned with the operational architecture described thoroughly in Appendices C through G, then I think you would definitely exceed the capabilities of any other framework. Just map back to them as needed.


With KVM and Xen, the rogue administrator can take a snapshot of your live machine, then explore at his leisure what is in the RAM of your VM. In particular, he will easily obtain the encryption keys for the encrypted filesystem, and then proceed to read all your files. By the very nature of the snapshot system, you will not notice it.

With OpenVZ, you don't have a virtual machine but a cheap emulation thereof, with a shared kernel (but that kernel pretends that each user has a whole machine to himself). The host admin has full control over that kernel, and thus can alter it (dynamically) to inspect the RAM of any running process. In any case, if there was disk encryption, it would be done by that kernel.

Either way, it can be done quite easily and silently.

  I'm asking to determine if a VPS is secure enough to handle personal emails capable of resetting passwords or if a dedicated server is necessary and justified considering the increased costs.

This entirely depends on what your passwords are protecting. An evil sysadmin will be interested in resetting your passwords only if he has something to gain which will offset the risks (as shown above, reading your emails will be quite risk-free for the attacker, but actually resetting your passwords should attract your attention and may result in trouble for the attacker if he was not careful enough).

Why don't you use Gmail like everybody else ? Google already owns the Internet, after all.


Get used to these.  You will get them regularly.  A lot of overpriced registrars make a living going around sending out e-mails and even snail mail like this to try to get website owners to pay for services from them.  The services are generally legitimate but overpriced and often sent prior to actually being needed.

They are correct that you must keep your WHOIS information accurate and up to date or you could technically lose your domain, but that's something you have to communicate to the registrar you use, not some random third party registrar that you aren't involved with.

If a third party registrar contacts you about your domain, just ignore it.  Google properly sorted it as SPAM.


Detecting and Responding to Email Account Compromise (regarding FINRA 12-05, ISAC/IC3 alerts)

If you look at the guidance provided, they give a couple of specifics that are relevant for IT Security:

Perform out-of-band authentication and verification of the payment instructions through a
validated contact channel.

Ensure your controls are enforced so that individuals cannot sidestep your current out-of-band authentication and verification

Leverage payment instruction and transaction anomaly tools to flag suspect transactions.

If you run statistical analysis tools to alert on anomalies, they may well already be picking up this sort of wire transfer fraud.

Use traditional security tools (DLP, spam filters, etc.) to search for e-mails with key
words like “wire + funeral”, or “wire + travel,” etc.  Clients and employees noted in 3
flagged messages should then be contacted directly by other resources within your
financial institution.

This is probably the key IT control here - even a basic DLP solution should allow you to search for these words at your mail gateway, which can pick this up rapidly.

It is a fairly standard social engineering attack, relying on the financial institution wanting to be as helpful as possible to the customer in dire straits. As staff are only human, enforcing IT controls is the simplest way to avoid a 'helpful' member of staff bypassing procedures and then becoming a victim.


How should I share the key of the AES algorithm in each client?

What you are trying to do is called key distribution. Key distribution requires you to use a secure channel. This can be:

Symmetric using a password (but then you need to distribute the password securely, so it is a bit of a chicken and egg problem).
A DB is not considered a secure way of sharing keys
SSL: assymetric encryption is one way of doing it, but in this case you could just implement SSL/TLS on your app in the first place. Similar to HTTPS is used (in fact it uses hybrid encryption to exchange a symmetric key that is then used with AES, or another symmetric cipher, for exchanging the data)
Another option is to use a hardware token that contains the encryption key (e.g. Yubikey). This can for instance be used to do mutual SSL authentication.

For your second part of your question:

This is highly debated, in general it depends on the use case of your application and how much data it encrypts. The more data it encrypts, the quicker you would need to rotate it. But this all depends on the algorithm etc. (e.g. AES GCM mode loses protection if more than 64 GB is encrypted on the same key. See NIST SP 800-38D section 5.2.1.1). So there's no single right answer. If you are going for the SSL option, every 365 days is probably your best bet.
Wether that variable is public or private does not matter. One thing to note is that rather than using String it should be char array (if using a managed language like Java or .NET) to prevent the key from being dumped to a memdump in case your machine crashes. The idea is that you load the key before each encryption/decryption and then overwrite the variable with 0's once you have finished the operation. This will reduce the likelihood of the key leaking.

Using SSL/TLS with certificate pinning in your application would be the easiest as you can actually use a different, mutually agreed symmetric key for each session you set up with your client.


A few thoughts:

Cookies aren't a great place to put refresh tokens at all, really. They're not the worst, but it's more common to use Local Storage and only ever transmit them when you're using them. Of course, they are script-accessible that way, but HttpOnly is actually very minimally useful as a protection and you need solid protection against XSS anyhow. When you want to use the refresh token, you POST it to the relevant URL.

Relatedly, I hope your cookies have Secure on them and are set to the right domain; and are ideally also SameSite; those attributes are vastly more important than HttpOnly. Not that HttpOnly is bad, it just doesn't do much. You can totally take over a session via XSS even if you can't read the cookies.

You say

I have implented it so that if the refresh token fails to validate the access token

I assume you mean if the server fails to validate the access token. Refresh tokens aren't code, or usually even structured data; they can't validate or even be used to validate anything else.

The method you've described is simple, in a way - the client neither knows nor cares about the refresh token and just occasionally a request takes a little longer than usual and comes back with a new Set-Cookie header or two - but it does require putting all the security-sensitive values into cookies and sending them with every request, and it means never pre-emptively refreshing the access token.

For clients that actively refresh (e.g. by POSTing the refresh token to the server's /refresh endpoint), there's two ways to know when to do it:

Do it when a request comes back with access denied. This requires that the whole site's interaction with the server be script-mediated (done through XHR/Fetch) but that's common these days and you can put a common wrapper around that API which checks the error case for that specific problem and initiates a refresh.
Do it on a timer, e.g. 90 seconds before JWT with a 10-minute lifetime expires, or perhaps cut it even closer if you don't expect peoples' computers' clocks to be off by very much. Requires knowing when the session token will expire, but that's easy if you can either read the JWT directly (it's a plain-text field in the JWT) or if you simply note whenever you successfully authenticate or refresh and just setInterval at that time if there isn't one already running, or setTimeout each time.

If you want to go the client-opaque route (via cookies or similar) but still want to do pre-emptive refresh, that's pretty easy too. Your server simply checks the expiry time in the JWT when validating it - that's part of the validation process anyhow - and if it's within some small window of its expiry but still valid, the server also tries to refresh the access token while serving the request. This can be done asynchronously, possibly on another thread, to avoid slowing down serving the actual request. (If the token has already expired, you need to confirm a successful refresh before starting to actually serve the request, which will slightly slow things down depending on how long a refresh takes.)

Sending both the access token and the refresh token on every request isn't ideal, but from a practical perspective the security model of a web app or web service is already predicated on both the connection and the server being secure. As such, it's not a meaningful vulnerability to transmit the refresh token more often than needed. Additionally, it still lets you get the primary benefit of JWTs (stateless authentication and authorization data that doesn't require either tons of DB hits or load-balancer-unfriendly caching) while addressing their biggest weakness (difficulty of revocation/cancelation meaning their lifetimes need to be short and some other, longer-lived token needs to be use for periodic refresh).


Why is a bind shell sometimes blocked when a reverse shell is not?

In order to understand why one might work when the other might not, you need to look at how firewall configurations work.

Consider an average employee computer. Most, if not all connections, will be outgoing first. Any incoming data would be in response to an outgoing connection. As such, a simple bind shell may be blocked by the firewall. I'll illustrate this below:

                                                   I want to connect to this host
                                                   on your local network.
                                                                     \
                                      That does not seem right.       \
                                      I will block this.               \
                                        /                               \
  +----------+               +----------+                               +----------+
 /          /|              /          /|                              /          /|
+----------+ |             +----------+ |                             +----------+ |
|          | |             |          | |                             |          | |
| Employee | | <-/-/-/-/-+ | Firewall | | <-------------------------+ | Attacker | |
| Computer | +             |          | +                             | Computer | +
|          |/              |          |/                              |          |/
+----------+               +----------+                               +----------+

However, a reverse shell looks to the firewall like the employee computer is initiating the connection to some remote host, and thus may accept it. You can imagine the situation like this:

            I want to connect to
          this host on the internet.
                /
               /                 Seems normal to me.
              /                     Go ahead!
             /                               \
  +----------+                               +----------+               +----------+
 /          /|                              /          /|              /          /|
+----------+ |                             +----------+ |             +----------+ |
|          | |                             |          | |             |          | |
| Employee | | +-------------------------> | Firewall | | +---------> | Attacker | |
| Computer | +                             |          | +             | Computer | +
|          |/                              |          |/              |          |/
+----------+                               +----------+               +----------+


Why are cookies sent with HTML page's cross domain requests but not with JS's XHR?

Cookies can be send with XHR if withCredentials is set to true. Contrary to cross-origin form submit or the cross-origin include of resources the application has actually control if cookies are sent or not. Since it is more secure to not include cookies in cross-site requests this is the default and the application has to explicitly enable it if needed.


Strong password for GPG key or encrypt password database with GPG key?

Security-wise, the weakest path to the data - in this case the passwords - is the relevant one.

As it seems that you are not able to remember a passphrase that is really good (and there are questions and answers here that cover how to generate ones that can be remembered very well), it does not really matter which of your options you choose.

I would propose to secure the password database with the GPG key and have that locked with a very good passphrase.

This approach has several benefits, one of it being that you probably use the key more often than other passwords in the database and by remembering that passphrase, you increase overall usability. Additionally, most operating systems allow to unlock a GPG keyring for all of a users session if that is acceptable security-wise, you can improve usability even more.


How to determine hashes/second in password cryptanalysis

For John the Ripper, @dr jimbob gave you the information: see the benchmarks page and use the --test command-line flag to make your own measures.

For rcracki-mt, the situation is a bit different. This uses a rainbow table which is a specific kind of look-up table containing, in a size-optimized structure, a lot of precomputed password hashes. Thus, the bulk of the hashing occurs when the table is built (with some other software), not when it is used. There is some hashing at usage time, but less, and hashing is not the only parameter in cracking speed.

Indeed, a rainbow table can be characterized by the number N of password hashes it virtually contains (i.e. there are exactly N distinct passwords which the table can crack; it will always succeed for one of these N passwords, and always fail for all others), and by its "internal chain length" t. The chain length is chosen when the table is built. The average costs are:

Table size: N/t chain ends.
Attack cost: t lookups, t2 hashes to compute.
Table building cost: about 1.7*N hashes, and a complete sorting step over the N/t chain ends.

A "chain end" is a sequence of bits of length a bit above log N, say a dozen bytes each. Depending on some technical details, you can save a factor of 2 in some places, which can matter in practice but does not change the big picture.

Rainbow tables are a variant of an older method with a clearer name: Hellman's Time/Memory Trade-Off. This points out that through the chain length chosen to build the table(s) (the t parameter), you save space (storage size is divided by t) but you increase usage cost (with a simple big table of precomputed hashes, you do one lookup and no hash; with the rainbow table, you do t lookups and t2 hashes for each attacked password hash). The trade-off is really between the available CPU for table building, the size of the hard disks, the available CPU at attack time, and the time taken for each lookup. Lookups are often the bottleneck at attack time: a mechanical hard disk will tolerate about one hundred accesses per second (these are not sequential at all). Of course, SSD offer vastly faster lookups, but are also quite more expensive per stored gigabyte, so the trade-off balance shifts.

Summary: for rainbow tables, "how many" passwords per second is the result of a combination of a several tunable parameters (chain length, but also number of tables and split between tables) and encompasses different hardware characteristics (CPU, disk size, disk technology...) for both the table building and the table usage. There is no simple answer; it really takes a lot of thinking and a lot of tuning with actual hardware -- and, of course, any actual performance result is subject to fast obsolescence due to shifting technologies.

It must be pointed out that rainbow tables are completely defeated by salts (as employed by any decent password hashing function). When salts are properly applied, only brute force with no precomputation can be used by attackers, and with no way to attack several password hashes in parallel; so you are back to John the Ripper.


I think you are expecting a protection from certificate pinning which it can not offer. This means that the actual technique used for pinning does not matter at all in your case. Certificate pinning only changes how the certificate gets validated by checking if the public key of the certificate matches the expectation. This check is done either additionally to the normal validation or replaces it.

Certificate pinning does not make your app magically secure against reverse engineering, tampering or shipping of a modified version. It makes it a bit harder for some reverse engineer to sniff and modify the transferred data since one cannot simply add another trusted CA to the trust store in order to trust a man in the middle. But it is still possible to bypass the certificate validation by ripping it out of your application or changing it. Or a reverse engineer could grab the data from your application before they get encrypted and after decryption while keeping the validation in place.

In general TLS does not protect against modifications of client or server. It only protects the transport between client and server against a passive or active attacker trying in between client and server to sniff or modify the traffic. And certificate pinning only hardens this part.


Most AV companies have a team of analysts that monitor incoming samples collected from a variety of sources.

These sources include but are not limited to:

acquisition of samples from sandboxed machines working in a honeypot
samples sent in via customers either automatically or manually
samples acquired from third parties including competing vendors

The first and last ones are generally the main sources of data.

Most malware collected from these main sources are replayed and actions the malware performs are then recorded. Once this has been done, someone at the AV vendor may end up reviewing it but in some other cases it is completely automatic--it all depends on the complexity of the malware itself, but more often than not it does require someone to look at the file itself.

Naming them is a different story. Some malware ends up getting the same or at least similar name across all vendors but how they approach the naming scheme usually ends up being up to the vendor itself.

Addendum since an edit was made

Since you added an item about heuristics, it should kept in mind that heuristics don't actually work for end users, but they do allow for AV vendors to become suspicious about a file itself. Certain behaviours like a file in a OS directory being edited or a security setting being changed can trip the detection when running in the sandbox.

Sometimes it isn't about what it does on the file system but instead what operating system API calls it makes or even instructions it throws at the CPU too. There are many examples of malware just making useless instructions or performing API calls that just don't make sense--such as a file disguising as a calculator application making calls to the printer spool even though the calculator app doesn't print.

To make matters more complicated, malware authors will also often encode the file using a packer, meaning that the malicious file gets encoded in a manner that requires you to 'unpack' it in order to know what is going on--think of file compression here. AV vendors may struggle with this because certain packers can come from legitimate sources meaning that you cannot take the packing part of the application as malicious because then you could be hosing other legitimate applications making use of said packer. This can make signatures a bit of a pain.


Go into your router config page and turn off 5ghz. Leave on 2.4ghz. and it should work, if your goal is to take down 2.4ghz.


Testing a hardware random number generator

There are several factors at play here:

The physical HRNG mechanism used inside the ARM microprocessor.
The supporting logic on the silicon inside the microprocessor.
The microcode deployed on the microprocessor.
The implementation of the RNG inside Linux.

According to the manufacturer, that particular chip uses noise from a reverse bias transistor, in an open-collector HRNG design. This is precisely the hardware I'm using in my current HRNG project, but much smaller. It's one of the cheapest ways to implement a HRNG directly into silicon; whereas I'm using discrete transistors, the ARM processor simply shrinks this to a few blips of silicon on the chip die.

We know that this mechanism is a strong source of randomness, because it relies upon a phenomenon called quantum tunnelling, which is known to be probabilistic and random. The basic idea is that electrons will randomly "jump" over the band gap inside the transistor, leading to a randomly fluctuating signal. We can then amplify this (simple PNP transistor amplifier will do) and interpret the output as either a 1 or a 0 by sampling the result at a fixed frequency - if it exceeds a certain threshold it's a 1, otherwise it's a 0.

One slight deficciency of this mechanism is that any DC leakage will lead to a skew towards 1s appearing more often than 0s. In order to get around this, we can use a simple trick called von Neumann decorrelation, which essentially involves encoding bit pairs 01 and 10 to 0 and 1 respectively, and ignoring all 00 and 11 pairs. This produces a statistically unbiased stream.

I can almost certainly guarantee that this is the mechanism by which it produces random numbers. There's one major alternative (two reverse biased NOT gates in parallel) but it's covered by an Intel patent, so I doubt ARM is using that. Unfortunately, the only way to know for certain is to grab some acid and decap a chip, then take a microscope and start reverse engineering the silicon. I don't happen to have the spare gear available for this.

The potential vulnerability that you might find in such exploration is that high frequency clock signals or other HF data lines are routed very close to the HRNG or its supporting logic, leading to a potential for interference. This is usually unlikely in ICs, but we're talking about high sensitivity applications here, so it's worth looking for. Even if it were the case, though, I don't see it providing a useful skew from a cryptanalytic perspective.

The next potential for exploitation is microcode. Recently, a researcher demonstrated that it was possible to patch microcode for Intel processors to look for unique patterns in the instruction buffer and detect when the RDRAND instruction was being used to fill the /dev/random pool. It would then identify the position of that pool buffer in the processor cache and effectively zero it, causing the zero pool to be copied back into system memory. This meant that /dev/random would constantly output the same attacker-controlled value, with obviously devastating results. If a similar but more subtle trick was employed in the ARM microcode, it might be possible to massively reduce the entropy of the HRNG in a way that is only known to the creator of the patch. Detecting such tricks would be difficult, but it could be done by extracting the microcode and analysing it.

Finally, the last problem is the RNG design inside the Linux kernel. The /dev/random pool is usually fed from a bunch of state-based sources, using a mixing algorithm that is built upon a cryptographic function. However, when RDRAND or similar instructions are available, the engine simply xors the data over the pool. This isn't exactly a good idea, because it makes it easy to screw with the pool data in a meaningful way by producing certain values. If the stronger mixing function were used, the attacker would need to break that (or do something more conspicuous) in order to gain meaningful control over the pool.

There is not an obvious answer to your question. Hardware random number generators can be very high quality, but it's difficult to analyse their implementation given only a consumer device. That being said, if you're going to distrust your hardware, you can't really make any guarantees in the first place. If you want to limit the scope of distrust entirely to the quality of random numbers produced, then design your supporting system around that fact.


What fields in a suspicious certificate should I look at?

Look at the Issuer field also!  As discussed at How feasible is it for a CA to be hacked?, you really can't trust all the Certificate Authorities out there, and actually the whole CA model is flawed.  So one field to look at is the Issuer field, and you might want a browser feature that notices if you're looking at a certificate issued by an untrustworthy CA.  This covers both CAs owned or overly influenced by countries that you don't want to trust with your data, or CAs that have flawed security or issuance procedures and have mistakenly certified fraudulent certificates.

Another case you should be alert for is the case in which your proxy server issues certificates  via a CA which has been baked into your browser - something that some organizations do because they don't trust their employees.   See e.g. some of the corporate proxy software like Blue Coat, which may also be used in Syria.


How web application firewalls protect application from DDoS attacks?

You might want to clarify if you're looking for DoS or DDoS protection. See this answer for more details.

In a typical web-application architecture, the WAF stands in front of your web-application, either in your network zone (e.g. DMZ) or within an external service provider network that filters the traffic for you. In case of a DDoS attack, the WAF will be hit by the traffic load before your web-application, and it can even become a point of failure in the network flow. Keep in mind that the objective of a DDoS attack is to  flood your bandwidth or resources. Configuring your WAF to reject or block incoming traffic based on rules/patterns/signature (e.g. source IP addresses, protocol etc.) might help, but it might not be able to handle the huge volume of incoming requests or connections.

In short, WAF is usually not enough to mitigate DDoS attacks. For details regarding further DDoS protection, you might want to look at this question, or this one.


For studying malware, you will be doing a lot of reverse engineering to understand what it does as well as a lot of analyzing systems for weaknesses to try to predict which ways malware development might go.

A Computer Science degree will be critical and you will want to focus on decompiling and low level development (assembly and C/C++).  Understanding embedded systems wouldn't be a bad idea either since one of the scary future places that malware will likely go is firmware and other places it can hide from current virus scanners.

A graduate level degree will probably be helpful (but not necessarily critical) as most bachelors programs focus more broadly on computer science as a whole and graduate work in reverse engineering will be beneficial.  I'd also suggest it is worth paying for a "good" technical/engineering school because a lot of cheaper Computer Science programs tend to focus more on what is needed for developing business applications than going in to the details of low level programing and decompiling.


Attacking a server on port 80 while only port 22 is open on the firewall

The only way to do this is if some running application or process were to forward port 22 (external) to port 80 (internal) on the server. Otherwise (provided the firewall and operating systems are the usual Linux / Windows / Mac OS) it is impossible in all scenarios I know of to do this. A good thing too - otherwise servers would be getting hacked all over the show. A server with a firewall with no ports open would be completely inaccessible unless it allowed an open port

The idea is that a running program "listens" on a port for a communication handshake.

For example, port 22 is listened to by some remote desktop software (such as PC-Anywhere)
http://www.speedguide.net/port.php?port=22

Port 80 is the standard web browser access port - meaning that website hosting server software (e.g. Apache, IIS) listen on that port for anyone pointing their web browser there.


Security risk for allowing accounts without captcha

It appears that people are using my website to annoy people with unwanted email.
After a little more digging, I found another step in the process.  The script would:

Create an account with an email like pa.rk.i.n.g.x.pe.rtdon.ma.na.h.a.n.@gmail.com and this sends out a verification email
Immediately change the account email address to a variant of the original email, such as par.k.in.g.xp.e.r.tdo.nmanaha.n@gmail.com and this sends out another verification email (this goes to the same place because only the dots are different)

So they send out 2 annoying emails and not just 1.
I'm now blocking the offending IP addresses at the firewall, but I need to find an automated solution to prevent this (captcha or something else).
I find this all very strange since I would think there are much easier ways to annoy people!


Some systems after install aircrack-ng suite have not only airmon-ng, they have airmon-zc. Check if is your case, it depends of the aircrack version. It's suppossed that airmon-zc (Zero Chaos) is more advanced.

Airmon-zc has the same behavior on cards that airmon-ng has in systems which only have airmon-ng, I mean it changes the mode of the card but not duplicate it. An example of what I say:

System on which airmon-zc doesn't exist:
After airmon-ng start wlan0 you'll get only one interface in monitor mode called mon0.
System on which there are both, airmon-ng and airmon-zc:
After airmon-ng start wlan0 you'll get two interfaces. First wlan0 in managed mode and other called mon0 which will be in monitor mode. If you execute airmon-zc start wlan0 you'll get only one interface in monitor mode called wlan0mon.

Test your systems and use airmon-zc instead if you have it available. To use intentionally airmon-ng on systems which have airmon-zc is useful to perform different tasks with only one card... for example you can create an AP with hostpad (managed required) and perform a DoS attack (monitor required)... this is used in some Evil Twin attack scripts.

Regarding the NetworkManager... Until version 1.0.12 NetworkManager is not able to change the mode without disrupting your network connection. If you have a lower version than 1.0.12 you'll need to launch not only the airmon check command... you can launch airmon check kill to kill directly the conflicting processes before the airmon start. But if you have NetworkManager 1.0.12 or higher, you don't need to kill any process, no airmon check kill needed. NetworkManager can manage the mode change without problems and you will not lose your internet connection with the change.

Hope this helps.


is it appropriate to set restrictions on a user's password?

Based on the Anderson formula -> http://joebi.blogspot.com/2006/12/how-to-defend-password-guessing.html

The most important thing is the password length, the second most important thing is the number of possible signs/letters/numbers.

If you want to enforce minimum 20 password length - you will be allright with just letters.

  20^24 = 16777216000000000000000000000000

If less than that but more than 15 you will be ok with alphanumerics.

  15^34 = 9707397373664756887592375278472900390625

What is often overlooked is phisical password security - hard to remember password will be often written on a post-it note, or can be easily recognized when someone is looking above your shoulder because you will type it slowly and carefuly. I prefer longer passwords with multiple words that are easy to remember.

iwillnevertellyouthepassword - is unbreakable at this time and you will remember it more easily than $%FD#sffe2e


1) Build the system according to the vendor's configuration guide. Look at NIST, SANS, Centre for Internet Security for security benchmarks for the product and harden the system.
2) Follow industry best practice for unique user names, role based access control, strong password policies.
3) Enable configuration backups and diffs to identify unintended or malicious changes, enable logging and review.
4) Run a vulnerability scanner against the system IP and see if there are known vulnerabilities; remediate these.

The above will cover you for industry best practice.. ISO, NIST, PCI etc


Is there a way to sniff packets of a remote IP address?

If you have control over the network, you can sniff traffic remotely by using a vlan as the destination for a span port and then trunking that to where you need it. You can do this over routed networks as well using GRE tunnels but you must control the network.
1) If you have control of the network you should be able to capture 100%
2) You can encrypt WAN connections using IPSec either from host to host or at the routers that connect to the service provider to prevent the service provider from viewing the data.
3) This sounds more like you are worried about spyware on your workstation. If you have malware on the box, it really doesn't matter what else you do. You need to clean the box.


Wireshark should be able to do it. However, the process is not as straightforward as you would have to scan the memory for the master secret.

Here is a tutorial on how to decrypt SSL without access to the master private key.

Identify the master secret and corresponding session key. This can be found in the "Server Hello" portion of the SSL handshake.
Configure Wireshark to use the master secret. Save the master key to a text file and configure wireshark to use the master secret file.
Decrypt the encrypted malware SSL session. Open the pcap file, right click on the session and select "Follow SSL Stream".


It's harder to reverse-engineer complex code. You can introduce extra variables, pipe data through multiple classes, create classes which don't actually do anything, and generally muddy the waters. Measures such as this make it much more complex to reverse engineer your code, however it makes it much more difficult to engineer your code in the first place and keep track of changes. Here's a good article which may help
Yes, making frequent releases with substantial changes in your code makes the job of the attacker more difficult, and the developers' as well
A phone being jailbroken does not mean its security has been compromised by an attacker. Phones can be hacked in ways that are undetectable, so spending time preventing your app from working on a jailbroken phone is a waste of effort and is more likely to annoy the app's legitimate users


Is it PCI compliant to use debit card pin as a mobile banking app password?

I think PCI Pin Security (v2) Requirement 1 is the most relevant to your question:

  "All cardholder-entered PINs must be processed in equipment that
  conforms to the requirements for secure cryptographic devices (SCDs).
  PINs must never appear in the clear outside of an SCD.

  A secure cryptographic device (SCD) must meet the requirements of a
  “Physically Secure Device” as defined in ISO 9564. For POI
  PIN-acceptance devices this is evidenced by their being validated and
  PCI approved"

So, unless the device meets the requirements of an SCD (I don't know of any devices resembling home computers or consumer mobiles meeting those requirements) it can't be done.  The details of encrypting and transporting the data are secondary to this (which, IMO, cant be overcome).


How can intelligence services be so sure that Russia is the culprit?

This is nearly a dupe of How do organizations check what has been hacked?  While that question deals with unraveling what, you're asking about unraveling how and by whom.

  What other possibilities are there to identify an attacker, when he knows his
  business and is hiding his IP/Info and not making stupid mistakes?

There are a lot of possibilities.  There's a lot more to remaining un-attributed than "not making stupid mistakes"!  it's fair to say, any APT (nation-state) actor is going to be attributed, eventually, by any nation-state level defender.  National Defense gets hella more resources than, say, you trying to figure out who took advantage of your Yahoo! credentials.

If you read the list of forensic steps that can be taken, the methods of backtracking rely on all the bits of data, each of which is a small piece of the puzzle.

Data you'll start with:

IP addresses used in the attack
Attack tools used in the attack and left on the target servers
Times of activity (as you say, not conclusive, but a piece of the puzzle)

To quote the bible, "By their fruit you will recognize them."  The advanced hacking groups build their own specialized tools, sometimes use the same IPs to route themselves through, and show enough consistency in times of activity to offset them from other advanced groups.

Some of this stuff can get really nitty-gritty.  Individual actors have been identified personally because their username was embedded in a directory that was embedded in a file compiled from source that referenced that directory.  Small strings found in one set of files have been enough to tie together that attack with another that also happened to have the same signature strings.

At the national level, the people who are working to defend and investigate have access to an awful lot of puzzle pieces, and can use them to attribute actions.  They may know that attack XYZ, for example, was blatantly tied to Russia, and that attack QRS has a significant overlap of indicators.  Enough overlap?  They conclude that QRS was also tied to Russia.

If you're interested in seeing more about how this is done, I strongly recommend reading Mandiant's "APT1: Exposing One of China's Cyber-Espionage Units"


What do you search for in Open Source code to be sure there isn't malicious code?

If you want to be 100% sure that some git repo doesn't contain malicious code, write it yourself; anything else will be an uphill battle.

If someone's really truly trying to hide malicious code in plain sight, then you probably won't notice it. Take for example, the infamous 2003 nearly-a-backdoor in the Linux kernel where this harmless code:

if ((options == (__WCLONE|__WALL)) && (current->uid == 0))
    retval = -EINVAL;

was turned into a backdoor like so:

if ((options == (__WCLONE|__WALL)) && (current->uid = 0))
    retval = -EINVAL;

(hint: instead of checking if you're root uid == 0, it turns you into root uid = 0. So pass in the flags _WCLONE|_WALL to whatever system call this is and BAM! you're now root.)

This example isn't directly relevant, but shows that malicious code in C/C++ can be really subtle. So if you think there's a chance that someone is playing hide-and-seek games in the code, move on and find a different project.

I often deal with a softer version of your question, "Is this open source library / tool ok to use?". My approach is to see if it has a good reputation; is it actively maintained? Do their github tickets give the impression that they follow a proper dev process? Do they publish regular changelogs, including security fixes? Does it have unresolved CVEs against it? If there are binaries, are they properly code-signed?

It's not foolproof, but it weeds out seedier projects. (if anyone has a better way of vetting open source projects, I'd love suggestions!)


Securing MySQL server from remote connection

The specific issues depend to some extent on the precise reasons you're opening the server in this way. However, I'm not sure what the difference between a direct MySQL connection dropping (which could happen anyway) and an SSL tunnelled connection dropping, in terms of levels of worry.

Changing the port is essentially security by obscurity. It might reduce the number of attacks seen slightly, but I've never seen particularly high levels of traffic against any database ports when compared with what is commonly seen against, say, SSH ports. There is no harm in doing it, as long as it is not the only security precautions taken. Don't expect it to stop anyone targeting your server specifically though.
SSL Connections for MySQL are sensible. Make sure your clients are aware of the specific certificate to expect, else it would be possible for a MitM attack to take place by interception and re-encryption (client->attacker is encrypted with attacker cert, attacker decrypts and sends to server using server cert, server responds to attacker, who re-encrypts the data to return to client)
IP restrictions are good. You can apply defence in depth here - IPTables to allow for connections to the server, then specific users within MySQL to only be allowed from specific source IPs. Be aware of any users coming from dynamic or shared IP ranges - this mostly applies to users who require access from mobile devices in some countries, but can also result from corporate NATs.
This is also good. Ensure that root still has a strong password, and does not rely on access from localhost as the only security precaution - in particular, allowing access to specific hosts indiscriminately, even if that is localhost, is a bad idea, since it weakens the security level to that of the lowest privilege user with access to that host.

However:

Are your clients storing access passwords in an unencrypted form? (e.g. are they using software to access the system which doesn't restrict access to the passwords if they click "remember my password"?) This might be addressed by policy (saying "don't click remember my password") or by technology (enforcing a specific client which doesn't have this function, or safely implements the function)
Is the stored data sensitive enough to warrant at-rest encryption?
Are you storing logs for the system, and monitoring these regularly?
Does the web server have access to any data it does not specifically require? (e.g. if it doesn't need to be able to read the MySQL users table, has it been prevented from doing so?)

Essentially, without knowing the specific details of your setup, any answer can only offer suggestions of what would normally be considered "secure enough". For a bank or for medical records, I would suggest that your setup is not secure enough, and that you should get in a specialist to help secure it fully. For a brochure website, with no transaction data, and no customer data, it's probably fine. For anything between them, it varies.


Periods in Common Platform Enumeration WFN (NIST Interagency Report 7695 )

Later on in the document in the following text

  In a formatted string binding, the alphanumeric characters plus hyphen (“-”), period (“.”) and underscore (“_”) appear unquoted.

So this does appear to conform to the specification.


Removing the SIM alone wouldn't prevent a remote hack if the phone was powered up as WiFi would still be available and therefore an attack vector. However, a phone that is off with no source of power is not remotely hackable. At least there's no demonstrated techniques or even published research that I know of which would make it possible. Without a power source there's no CPU or antenna operation, it's just a sophisticated brick.

The thing is that in order for this cold wallet to be useful it will need to talk to something - as some point you will need to turn this on and connect and then it's just as vulnerable as anything else. Android is designed as a vehicle to get your personal information to the outside world so is chatty by default, however there are some Android ROMs which are designed with security in mind, it would be best if you installed one of those and limited the operation of your cold wallet phone to the bare essentials.


SMIME email decryption using a private key - what am I doing wrong?

Try using openssl cms instead of openssl smime.  See https://www.misterpki.com/openssl-cms/ for a good example.


How secure is Windows 8's Picture Password login?

Potential weakness: predictable passwords.  I expect the primary weakness is likely to be that users choose a "picture password" that is guessable or predictable.  If the user chooses a predictable set of locations/gestures, someone may be able to guess the "picture password".
For Microsoft's evaluation of their own design, you should read this Microsoft blog post on the security of Windows Picture Password.  They provide some simple calculations to estimate the strength of a picture password, and to estimate how many bits of entropy they provide.  However, I think their security analysis is overly optimistic, because they make several dubious assumptions:

First, they assume that all locations in the image are equally likely to be chosen by the user.  I think this is unrealistic; for any given photo, I think some locations are more likely to be picked than others, which it will be predictable which locations are more likely to be picked.  Someone is probably more likely to choose some unique feature in the picture, not a random location in the middle of a broad expanse of blue sky.  For instance, in the video you shared, the user chose to tap on the location of a window in the image.

Second, they assume that the location of the user's three gestures are all chosen independently.  In practice, I don't think this is realistic; I think there will often be some pattern.  For instance, in the video you shared, the user chose to tap on three windows in sequence.  If you've guessed that the first tap location is over a window, then it would be natural to guess that maybe the next two are on some other windows, too.

Third, they assume that users will use a combination of taps, circles, and lines.  (They have three kinds of gestures: tap on a specific location, circle around a particular location with some radius, or drag your finger in a line from one location to another location.)  However, tapping is the quickest and easiest and most natural of these gestures.  Therefore, I would suspect that many users will just tap on three locations, and not bother with the other gestures.  At the same time, tapping has the weakest security, because of the limited number of locations on the picture that someone is likely to select.  Therefore, I think some of Microsoft's calculations about security level may be based upon a somewhat optimistic view, and users may not behave the way they are assuming.

As a result, I suspect that the entropy of picture passwords might be significantly lower than the estimates found in those Microsoft blog posts.
Microsoft has a follow-up blog post where they give advice to users on how to choose a hard-to-guess picture password, but I'm not persuaded that the average user will be aware of this or will bother.
That said, Microsoft has deployed one very significant defense against guessing attacks: you only get 5 tries to enter the picture password.  After 5 tries, the system locks you out and requires you to enter the textual password.  Therefore, someone who gets ahold of your phone will only get 5 tries to guess your picture password -- and if they don't get it right within 5 guesses, they're done.  If implemented properly, this seems like a powerful and effective defense against guessing attacks.
Potential weakness: the weakest-link effect.  There are now two ways to log into your account: either enter the text password, or enter the picture password.  If an attacker can guess either one, he can get access to your account.  Therefore, your security is only as good as the weaker of those two passwords.  To be secure, both of them need to be well-chosen.  This might trip some users up.
Potential weakness: smudge attacks.  Suppose someone gets ahold of your phone.  Another way they could try to guess your picture password is by looking at the pattern of smudge marks on the screen left by your finger oils.
Past research has looked at smudge marks, in the context of phone lock screens.  They found that this attack can be surprisingly effective.  If you hold the phone at just the right angle to the light, you can often see the smudge marks clearly.  And if they use a digital camera to take a picture at the right angle, the smudge marks become even clearer.  Amazingly, they found that the smudge marks remained clearly visible even if the user put the phone in their pocket -- you might expect this would wipe the fingerprints off, but nope, they still remained visible!
The research is described in the following paper:

Smudge Attacks on Smartphone Touch Screens.  Adam J. Aviv, Katherine Gibson, Evan Mossop, Matt Blaze, and Jonathan M. Smith.  WOOT 2010.

While I haven't seen any work on this in the context of Windows picture passwords, I would expect that similar methods might help an attacker guess the picture password and significantly reduce the entropy in the password.  Fortunately, the attacker only gets 5 guesses, which should help make smudge attacks harder.
For instance, suppose the attacker gets lucky and there are only 3 smudge marks on the screen.  Then there are 3! = 321 = 6 possible re-orderings of these.  The attacker gets 5 tries to guess the picture password.  So, in this scenario, the attacker has a 5/6 chance of guessing the picture password correctly before being locked out.  That said, this is almost the best possible case for the attacker, and in practice, the attack will likely be harder to mount, because the attacker will have to guess which of the smudges come from the picture password and which ones come from other use of the touchscreen.
As a lower-tech and more-extreme version of this attack, consider the following photograph of a PIN-entry keypad:

Can you guess the PIN, based upon the wear pattern on the keys?  Yes, very good, I knew you could!
Potential weakness: shoulder surfing.
Another possible attack is that, if someone is looking over your shoulder when you log in, they will find it very easy to notice where you are tapping.  In fact, it will be hard not to notice the picture password being entered.  So, entering your picture password while you are in view of someone else is not safe.
Advantage: convenience.
I expect the picture password to be easier for users to use and more convenient.  Right now, all of the methods for authenticating on mobile/touchscreen devices are a pain in the butt.  Entering a text password on a touchscreen keypad is a horrible experience, which just drives users to choose poor, short passwords -- and that's not good for security.  So, I expect picture passwords will be good for users.
Advantage: no worse than the alternatives.
Right now, on mobile platforms, the main alternatives are asking the user to enter a 4-digit PIN or asking the user to use an unlock gesture, as is done on Android or the iPhone.  However, those have their own security weaknesses as well, and they may be no better than the Windows picture password.
Therefore, for mobile platforms, the Windows picture password may represent a pragmatic and reasonable tradeoff between ease of use and security, one that is sufficient for the average user.
Conclusion and takeaways.
My personal impression is: it seems like a plausible scheme, one that might be adequate for many or most users.  Overall, it feels like a pragmatic choice to me, given the engineering constraints -- I would be hard-pressed to try to come up with something better.  However, it is a new scheme, and more research will be needed to better understand how secure it is, in practice.  The security of the scheme will depend heavily upon how users use it, and it's probably too early to say whether it will work well for typical users or not.
Related schemes.
To read about other schemes for authentication on mobile or touchscreen devices, see Are the iPhone “connect the dots” passwords secure? and Is Android's Password Screen Lock Enough Data Theft Protection?.


Unsecured wifi but requires mac address... Secure?

By unsecured WiFi, I'm guessing you mean 'open' and unencrypted. Packets on an open WiFi connection (one that is not protected by, say, WPA2) are susceptible to sniffing. All information is being transmitted in plaintext format. An exception is if you are visiting an HTTPS link and have end-to-end encryption on that website. All other HTTP traffic on an open WiFi is susceptible to sniffing.

Some organizations use MAC address to register a device before allowing it access to the Internet. In the event of a policy violation, they can look up the MAC address attached to the IP at the time and identify the machine -- and possibly the user. However, this is not an effective procedure since MAC addresses can be spoofed using tools like macchanger. Using such tools it is easy for even script kiddies to spoof a MAC address. Quite easy to do on a Linux machine. MAC addresses could be spoofed to any address such as 00:00:00:00:00:00 or a valid MAC address of another user.


Is it safe to view local pdf files in a browser?

It is generally considered safer to open PDFs in browsers, because they are better sandboxed than the other PDF readers installed on your computer. The sandbox should prevent the browser to access your local files (I'm simplifying a little). Anyway, if the PDF is malicious and targets (for example) Adobe Reader, nothing prevents Adobe Reader to access your local files, so in any case using a browser does not make you more vulnerable against this attack.


I was logged in as another user to a site, how?

Without knowing the website itself and the processes / code behind it, it is hard to exactly pinpoint what caused you to be able to login as a different user on those websites. There are a lot of possible issues, some are listed down below.

The website might have a vulnerability that causes some users to receive the same session or cookie ID. When doing this on purpose, it is called session hijacking or stealing cookies, you can look up exactly how this works;
Another possibility is that you followed an URL which was not protected and you ended up as a different user on the website.

As explained in the comments, it is really hard to bug track or reverse engineer what happened without knowing what might have caused this behaviour. You can report the issue to the website owners to see if they can fix the issue. You can find the support email address of Alltrains in their terms and conditions, listed here:

https://www.alltrails.com/terms

There are a lot of vulnerabilities that might cause such behaviour and especially for the lesser known website I could image it not being completely secure (then again, what is).


If you see this question here: Where can I find good dictionaries for dictionary attacks? you will find many good sites for downloadable dictionaries. However for language specific dictionaries I would recommend these:

inside.pro.
ox.ac.uk

They got a whole lot of different languages.


Are there risks to allowing cURL from my machine?

Well, it's possible that curl contains a yet-undiscovered flaw, such as a buffer overflow, and that a carefully crafted site out there might put up data that, when pulled with curl, would run malicious code on your machine with the rights of the user that ran curl.

Depending on how isolated your machine is, opening up a hole in your firewall for curl could lead to another, malicious process on your machine using the same firewall hole to extract data from your machine and upload it to one of the sites curl was allowed to connect to.

The first scenario is unlikely, but within the realm of the possible. The second scenario assumes your machine is highly isolated and you're worried about secrets being extracted from it. In that case, it probably shouldn't be connected to the internet at all, so scenario two is probably not really relevant.

If you're talking about a normal desktop machine, I wouldn't worry about curl.

Updated to answer your comment: A correctly functioning curl itself which was under your control wouldn't send arbitrary data out. But if I managed to install a malicious program on your machine, I could then tell it to use curl to post data I stole from your machine to one of the sites that you allowed curl to connect to.

The technical explanation for this is that curl sends an HTTP request and receives the answer in an HTTP Response. An HTTP request can contain arbitrary data; this is how HTTP is designed. If you only want to allow very specific HTTP requests, you'll have to configure your firewall to use deep packet inspection to block everything but white-listed HTTP requests.

Even that will not be enough to be perfectly safe, since once there is a hole in your firewall, another process might mimick curl and send out information using a covert channel (such as sending out information not in the actual bytes it sends, but in the frequency of the requests).

However, you probably don't have to worry about such attacks unless you're doing very important or very secret work that might interest state-level adversaries.


Where to find ransomware samples to make demonstrations?

Perhaps you don't need ransomware to demonstrate what happens.  You could fake the output of the attack using openssl like this:

Encrypt:  openssl aes-256-cbc -pass pass:pwd -in victim -out victim.ransom && rm victim

Decrypt:  openssl aes-256-cbc -pass pass:pwd -d -in victim.ransom -out victim

However, it looks like you may be more interested in demonstrating the activity of the ransomware file system scanner, to prove that your isolated VM can't encrypt the files of the host system or of other guest systems.  That's rather like proving a negative.  The best demonstration might be to show how find works, because that's exactly what ransomware would have to do.

Create a file named /tmp/sacrificial_pic_<vmname>.jpg on each of the VMs, including the VM hosting the fake malware, substituting the machine name in the filename above.   Run the find command on the VM hosting the fake malware, like this:

find / -name \*.jpg -print

This will emulate the activity of malware searching for picture files to encrypt.  The only sacrificial JPG your find command should discover is the one on your local VM.


How does Bitlocker + TPM prevent me seeing the HDD contents with another OS?

Nothing is stopping this. What the TPM is doing is checking the integrity of various boot-time components and only unsealing an internal password if these components have not been tampered with. It can be additionally configured to require a PIN code, but that is not strictly necessary. The reason the drive does not automatically decrypt on a Linux system is simply because Windows is communicating with the TPM, asking it to attest the state of the system.

The key is kept sealed inside the TPM itself. The purpose is not to prevent you from decrypting the disk if you have both the computer and the drive, but to make it impossible to decrypt the disk if you have only the storage drive but not the computer itself. If you have physical access to the entire device, including both the drive and the TPM, you will be able to decrypt the drive.


What does this Bruce Schneier fact mean?

Answered by @SteveSether in their comment.

  Almost certainly it's referring to Hans Reiser, an OSS software developer who murdered his wife in 2006. en.wikipedia.org/wiki/Hans_Reiser (He did it, and later lead police to where her body was buried).


How can I verify the GPG signature is valid?

I'm not entirely sure how it all works, or the correct terminology,

The correct terminology is called verification.

  I guess it depends on how paranoid one is.

Yes, absolutely. There is no technical solution to these kind of problems. If you are paranoid enough, you wouldn't even trust your computer at all, because it could have been fiddled with before you purchased it.

  What would be the minimum reasonable assumptions you would have to make about the environment/process in order to be as confident as possible that a signature and the content it signed is valid and unmodified (short of meeting the developer in person and exchanging key fingerprints)?

You probably want to take a look at the warning page of Tails, which gives a pretty good overview of possible attacks. There is also a section dedicated to the process of verification guiding you through the process step-by-step

Personally, I would argue that it depends pretty much on what you are up to. For most of us, it should be good enough to use secure connection (e.g. SSL/TLS) and compare the downloaded version against some sort of simple hash. This rules out errors during the transmission of any file and really sloppy attempts to get you infected. Signatures are fine, too, but they make only sense if you make sure that the keys being involved match up to your expectation, which sound easy in theory, but turns out to be quite hard in practice.

If you are really not sure as to whether your computer is trustworthy, it would probably be a good idea to get a second opinion in form of another computer. Ideally, this computer would be completely independent of the first one, so it would be hard for an attacker to get both under his control.

  (short of meeting the developer in person and exchanging key fingerprints)?

GPG in its normal mode of operation relies on a web of trust, which is quite a good model, but obviously is not perfectly secure. The beauty of it is that you not necessarily need to meet the developer itself, but only need to know someone who knows someone, who knows the developer. You can use this chain of trust to verify the authenticity of any signature.

  I'm trying to figure out if there is a way to be 100% sure that a GPG signature is valid.

You won't get this 100% figure in practice. It is always a possibility that someone got hold of the private key. He then could sign whatever the heck he wants to.


Securing access to information stored on a home based Nextcloud server acessed via self-signed SSL certificate and home vpn

To take apart your setup, using TLS alone provides complete confidentiality for application-layer content. Wireguard provides confidentially for all of your traffic that is sent through it.

Your question doesn't specify whether NextCloud is only accessible over the VPN. If so, the main advantage of this is that the VPN acts as another level of access control to the NextCloud service, but doesn't really provide additional confidentiality since TLS is already used.

The main threat would be that your phone (or another device you access NextCloud from) is compromised, at which point an adversary could potentially see everything you see on NextCloud. But this is fairly unlikely. Or, there could be a critical vulnerability in Wireguard that is not publicly known, or you haven't patched it. But this is also fairly unlikely.


Convince an executive to mandate HTTPS use on Intranet web servers

Insider threat is always a possibility, but managers are always going to react defensively when they (and by extension, their team) are brought under scrutiny. Especially when you confront them with direct evidence of an underling's misdeeds.

Don't bring employees into it. Rephrase it in terms of compromised credentials-- "it's not about what Jenny in accounting might do, it's about what someone who steals her credentials will absolutely do."

...even if Jenny truly is a menace to the company.

  If someone we don't trust is in our network, we have a much bigger problem.

It's about threat mitigation. Just because an attacker has gained a foothold doesn't mean they've already started to enumerate or spread or pwned your entire infrastructure. For all you know he's contained on one machine, where he's stuck trying to guess at server locations and credentials to the next. This is a small and simple problem to remediate.

But with credentials floating around in the clear, if he starts eavesdropping on network traffic, he can obtain new sets of credentials to masquerade as and new locations to breach. The scope of his infiltration expands quickly, as do the number of places for him to maintain persistence in your network. Only now has that "bigger problem" materialized.


Changing policy to allow USB drives. Why should I try to stop it?

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

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

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

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

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


Secure no-login REST API for very few clients

To answer your question you have to first gather some information:
- What risks are there you want to mitigate through security?
- What Prevention techniques do you want to employ, and how much money are you willing to spend on them?
- Do you have any form of intrusion detection?
- Do you use a firewall?

for the rest, HTTPS is a good step, but for this type of "research" a verification with client-side certificates might be apt. this means not only is the data secured in transit. but only clients that know your "secret" way of communicating with you can (e.a. the client certificate has to be valid or the server won't even listen to the request)

for storage of critical data mongoDB is not the best solution (it can loose data or even not store it at all) But that is a discussion for another thread (like programmers or sysadmin stackexchange).

On the looks of things, for a wide scale use its not that bad. just add some intrusion detection and misuse detection (no one should be trying random strings on your back-end without getting banned y your firewall for at least 10 minutes after each try, incrementing exponentially with each try, or other security methodology).

Also, at the moment you have no protection against replay attacks. add some time sensitive part to your data that locks out after some time (like a session cookie does or a CSRF token does). a counter that increments after each request send could do this trick already.


How to check if iCloud password popup is legitimate?

The safest thing to do would be to cancel that popup and then select app store from the main menu and if it prompts for your ID, you can enter it. OSX will then cache this information. Unless your system has been so compromised that the app store app has been hacked, this should be safe.

More than likely, the reason this popup has occurred is because your OSX has detected there are updates to be applied. However, you have not signed in and therefore it cannot connect to the app store to download the update. One way you could verify this is to cancel the popup and then select updates from the app store and see if there are some updates waiting to be applied.


Clarifying MITM attacks and Digital Certificate requirement

It's often not only the case that "payment information" is the only sensitive information.  If your portal requires some sort of "login" (which it undoubtedly does), you allow many parties in between (Internet Cafe owners, ISP's, "hackers", employers, govermenments, ...) to see these credentials and take over the account.

If your portal has anything in terms of recurring payment what they can setup from your unsecured side, or any requests that would affect the subjects account, you offer no protection towards that.

SSL certificates and the benefits they offer (even if it's just a professional and trusted image) far outweigh the cheap price.


Can Paypal be used to verify a user's identity?

Paypal do offer an Address Verification Service. Paypal won't tell you the customer's address, but you can ask Paypal "Does this address match the credit card billing address?" and get a yes/no response.

https://www.paypalobjects.com/en_US/vhelp/paypalmanager_help/using_address_verification_service_(avs).htm


Admin privileges from Random regedit modification

In HKLM\Software\Microsoft\Windows\currentversion\run or runonce, I would try to insert a new string with this command:
cmd.exe /c net localgroup Administrators <my windows account> /add

With that, at the next startup of the computer, your account will be in the admin group.

Or I would try to modify the proxy paramaters of Ie in \CurrentVersion\Internet Settings to be able to capture http traffic.

However, for writing in those keys, you must be logged as admin...


Unfamiliar user agents 'CON 1.0 urlexists' and 'VANILLA 1.0 vanillastub' - are they malicious?

In many browsers using add-ons users can set agent to any value they want. Also applications can set this header to any value they want. That's why based on agent header it is impossible to say if this is a malicious request or not.


Am I protected from USB autorun malware on Windows 7?

When you plug a USB key in, a considerable amount of things happen. The OS first talks to the USB device to know what kind of device it is and what it can do. Then, if the device says that it is a kind of disk, the OS will look for a filesystem on it, then mount it, and explore some of the files. Depending on what files were found and their name, the OS will suggest a choice of actions to the user (that's the popup you see). Any phase of that process could have exploitable bugs, and indeed numerous examples of these have historically occurred (for instance, the PS3 Jailbreak from last year is a USB device which, internally, announces itself as a hub of four devices, one of which rambling incoherently on the USB bus in such a way that it triggers a buffer overflow in the OS USB driver).

Hence, while the current state of affairs on Windows is that the OS will not by design run malicious code automatically, it may still do it by mistake. To my knowledge, there is no currently published exploit which does so, but it would be implausible that all that code is bug-free.

As a side note, what looks like a plain USB stick may, internally, behave quite differently, and (for instance) show itself as a keyboard to the OS -- and begin "typing" immediately. The possibilities are almost endless. And a bit scary.


Attack on the custom token-based sha256 security scheme

The length extension attack that @Tinned_Tuna talks about would have allowed you to generate forged tokens with a "public text" of your own choosing (within some format constraints due to SHA-256 padding, though), but only if the secret had come first in the hash function. By inputting the secret last, this specific weakness is avoided.

Another, less serious weakness related to the input of the "public text" first is that, potentially, as an attacker, you could try to build a SHA-256 collision, have one message of the colliding pair be authenticated by the key-owner system, and the hash value will be valid for both messages. In other words, using SHA-256(public+secret) makes the algorithm only as strong as collision resistance of the hash function, instead of preimage resistance. This is not a serious problem because SHA-256 has a 256-bit output, which makes it immune (in practice) to collisions; that's more a theoretical issue in that you do not get your money worth (you have to use a 256-bit output to get 128-bit security).

An handwaving way of stating things is that, in such constructions, you need to input the secret key at least twice, at the beginning and at the end of the computation. But, really, you want a MAC; that's what your "tokens" are about. So, do yourself a favour, don't try to invent your own algorithm; instead, use something which has been carefully designed and studied for years, even decades, and provides the kind of security you want. This is called HMAC. HMAC uses an underlying hash function (e.g. SHA-256) but does it well, with the secret key inserted at the right place so as to avoid the tricky pitfalls implied by using an actual hash function, as opposed to the mythical beast known as a "random oracle". If you study HMAC, you will see two nested invocations of the hash function, with the secret key used twice.


Is tokenless (specifically SMS) 2FA a security compromise over OTP tokens?

a) Is tokenless 2FA (particularly SMS based) a security compromise over traditional tokens?

Yes SMS is better than just a password but the weakest of the forms of 2FA.

The main security risks are:

Number redirection
Phone stolen
Transaction performed on the phone. This is a major one with the growth of smartphones and tablets capable of receiving iMessage type messages

Also like you said the operational considerations:

SMS coverage. The options you stated such as sending two codes or a day code reduce the strength of the one time password as it is valid for a lot longer period and thus providing a greater window for compromise
Cost of sending the SMS, especially if you need to send internationally
Require battery

That said it is still the most convenient for users because:

Most people have a phone capable of SMS and carry it with them always.

It also has a security benefit in that:

users are far more likely to notice a missing phone rather than a missing token
if the seed file and/or algorithm is compromised (e.g. RSA breech) it is far easier to replace a fleet of soft tokens or change the SMS OTP seed file and algorithm rather than a fleet of hard tokens

b) Are physical tokens still popular just because they're tried and tested, with companies like RSA trading on the reputation they've established, or is there still an objective case for sticking with physical tokens?

There is a objective case as they provide a fit depending on your threat model.

Of course there is also change resistance. Large companies that have deployed hard token infrastructure, deployed tokens, trained their users have to build a business case for the project not just that say SMS or soft tokens are cheaper and more convenient. Although with the RSA breach for example I know of quite a few companies  that took the opportunity to move to soft tokens.

c) Have people found that SMS based 2FA is impractical for regular users and found themselves deploying physical tokens to those users?

The only times I have heard this are:

A significant enough population of users do not have phones or phones capable of soft tokens and the company cannot be seen to discriminate
Users are already trained in using hard tokens
Users already have a hard token and it is easier to re-use than deploy and train for SMS
International users and the cost of sms or difficulty sending local sms is prohibitive

d) Are the solutions such as "day use" codes and multiple codes in a single SMS much of a security compromise compared to the default of single codes being sent and stored in an SMS?

Yes as they reduce the strength of the one time password as it is valid for a lot longer period and thus providing a greater window for compromise

e) For users of smartphones, is it a no-brainer to deploy soft tokens rather than rely on SMS based 2FA?

Not necessarily. A threat model still needed, a soft token still can be compromised more easily than a hard token. Smart phones are computers, they can still get malware, applications can gain access to your seed or OTP and transmit it elsewhere.

Also the operational considerations mentioned above. If it is a mining environment is a hard token that needs a new battery every few years and is more resistant to dirt, variation in temperature, liquids going to be better?

f) Can anyone direct me to some appropriate literature that I should be reading to really get a feel for some of the above issues?

Oldie but a goodie:
http://www.isaca.org/Journal/archives/2007/Volume-3/Pages/Analyzing-the-Security-of-Internet-Banking-Authentication-Mechanisms1.aspx


Using a VM to access internet when malware blocks internet access?

It can very well be that your NIC of your VM is bridged to your physical machine, which means the firewall rules which apply to your physical machine, may not apply for your VM.


Knowing Hash Algorithm from Hashed String

There is a tool for identifying hashes if they are identifiable:
http://code.google.com/p/hash-identifier/


Why only script-src unsafe-inline is reported as a high severity finding?

I don't think you are missing anything, this does seem to be an error in googles CSP evaluator.
script-src-elem is used to control the source of script tags (inline or external; see also the spec). You can test this yourself, eg with:
<?php
header("content-security-policy: script-src 'self'; script-src-elem 'self' 'unsafe-inline'")
?>
<script>alert(1);</script>

Viewed with Chrome, the payload will fire (Firefox does not support script-src-elem). If you remove unsafe-inline, the CSP will block the script.
So we can see that script-src-elem 'unsafe-inline' is indeed dangerous.


Self-signing a document is not meant to prove that you are you or that you wrote it. It provides a way for you and the recipient to be assured that you are using the same file.

In order for this to work, yes, there needs to be some sort of agreement between the parties that they are talking to who they think they are talking to, but assuming that is established, then the parties know that the file is the same.

Have you seen file downloads where they list the MD5 hash of the file? Same idea. By comparing the signature to the trusted, known source reference (the hash, or in this case, the digital cert) the recipient can be assured. For a file, where the source might ultimately not be known, by including a name, then anyone who receives the file knows who to contact to check on its authenticity.


"Evil maid" attacks can be anything that is done to a machine via physical access while it is turned off, even though it's encrypted. The name comes from the idea that an attacker could infiltrate or pay off the cleaning staff wherever you're staying to compromise your laptop while you're out.

For an encrypted device, the most likely evil maid attacks are some form of keylogger, either physical or software. Physical loggers are all-but-impossible to detect in software but can be found by physical examination (although depending on the available space inside a laptop and how easy it is to disconnect the keyboard, it could possibly be done in a way you wouldn't see without disassembling it again yourself...). Software keyloggers are a major threat, though.

The VeraCrypt bootloader (which takes your password and decrypts the encrypted volume or at least the next required part for booting) must itself be decrypted - if it were encrypted, it couldn't execute without something else to decrypt it - so it's a prime target for a place to put a software keylogger. Take an encrypted hard disk, attach it to another machine, replace the VeraCrypt bootloader with a compromised one that secretly saves the password, and put it back in the victim's machine. Next time the victim boots the computer, their hard disk password is logged for later retrieval. VeraCrypt attempts to detect this by computing a cryptographic fingerprint of the bootloader to see if it's been tampered with, although a skilled attacker could thwart this as well unless the machine is using a TPM or similar that checks the bootloader against a key which the attacker can't overwrite.

So, it looks like that verification of the bootloader failed. That's why VeraCrypt is telling you to change you hard disk password immediately. The attacker probably can't steal the password as you enter it - it would be a multi-stage attack instead, first compromising the bootloader and then retrieving the password later after you've had a chance to enter it - but if they get to the machine again after you unlock it once but before you change the password then they could steal that password (and all data on the disk).

Of course, it's possible that something totally innocuous happened and there is no attacker. Anything that messes with hard disks at a low level, like partitioning tools, backup/restore tools, OS installers/updaters, or a few other things could potentially invalidate the bootloader fingerprint without actually doing anything malicious. Changing the password is still probably a good idea anyway, though... when was the last time you did that?


Storing 2-way encrypted sensitive data in web app

I wouldn’t encrypt directly with the user password. Rather use the users password, passed through some key-derivation like PBKDF2 — and use the output of that as a Key encrypting key (KEK)

Then use the KEK to encrypt a unique key that is used for encrypting/decrypting the user data. This also simplified user password changes, but beware, users who lose their passwords will also lose access to the data, for many use-cases this is unacceptable.

The problem with this approach is that someone in possession of the password would be able decrypt the sensitive data. Plus weak passwords will be a weak-link in the setup.

A separate approach would be to generate a unique key for each user, and encrypt that key with something like Amazon KMS. That way you’d be able to decrypt the data using Amazon KMS and the encrypted key.

This way, if someone dumps the database, the sensitive data is still secure since the attacker won’t have access to the sensitive data, because they wouldn’t have access to your key on Amazon KMS.

The downside is that a full-blown compromise of your aws account would compromise the data — but hopefully you’re monitoring to KMS and can see suspicious activity before things get out of hand.


Can Network Admin Make changes to site if I've accessed the site in edit mode?

A network owner can (but is very unlikely to in a home network) see every byte that goes over their network.  However, the connection to Google Sites is encrypted through TLS (HTTPS). Those bytes would look like meaningless gibberish to them.

It is extremely unlikely that they gained access to your account simply by you connecting through their network, since Google is very good about this type of security.

The URL of a site's edit mode also does not contain sensitive account information. It may identify the account, as it identifies the site, but that is not enough by itself to gain access.

If the support person gained access, they did it with more information than the URL.


Saving unhashed first name and last name on a non-encrypted database on phone

I have been tasked to secure this data. Either encrypt these two fields or save them in the storage of the phone.

Modern smartphones (Android, iOS) already encrypt their flash when a pin or passcode is set. Your app's storage should be isolated and cannot usually be read by other apps. Assuming your app doesn't ask your user for a master password, any additional encryption you add can just be defeated by reverse-engineering your app. If you could store a per-user encryption key on the server side then you could just store the name and pass on the server anyway, so that's a pointless approach.

  How risky is to have the first name and last name saved in clear. Is it a security risk?

I would call it a minimal security risk in most contexts except a few. If your app contains medical data or allows medical data to be inferred (e.g. if your app was for, say, a HIV support group) then you may be beholden to legislation such as HIPAA, not to mention a moral obligation to protect those names. The same goes for things like dating apps where sexual orientation or gender expression are stored, which may be problematic to some people's family situation, or worse under certain governments. You can continue this line of thinking for other threat models of this ilk; effectively, if the use of your app may indicate behaviour or beliefs that could lead to persecution or harm, then you should strongly consider this while developing a security program around your app.

In some jurisdictions a name alone is considered to be personally identifying information (PII) that you have a duty to protect. In the UK, for example, this is covered by the Data Protection Act (DPA). However, the general way this legislation is written usually only makes you liable if you were negligent. I don't think that storing a name alone, in an app's isolated storage, could be considered negligent. The key factor here is that the PII is stored using standard practices (app isolated storage) on a device that the user controls, and the user is responsible for the security of their own device. If they root their device and install a shady app that steals their data, you cannot control for that.


Why use an authentication token instead of the username/password per request?

When you use an "authentication token", the simple presentation of that token by the client grants access (as long as the token is deemed valid by the server). If you store the tokens "as is" in your server's database, then an attacker who could get a glimpse at your database will immediately learn all the tokens, allowing him to send requests in the name of all users for whom a valid token still exists in the database. This is bad. Hence the recommendation of storing only a hash of the authentication token.

The advice about bcrypt for authentication tokens is misguided. Bcrypt, like all functions dedicated to password hashing, is meant to be used for passwords. Passwords are weak; they are vulnerable to dictionary attacks. To cope with their inherent weakness, the password hashing function must be salted (to prevent parallel attacks and precomputed tables) and must also be awfully slow (through a huge number if internal iterations). This makes password hashing functions expensive. So you don't want to use a password hashing function unless you need it, e.g. to hash a password.

An authentication token is not a password; it is a random value which was generated and remembered by a computer, without any human brain involved in the process. As such, if you generated the token properly (at least 128 bits, obtained from a cryptographically secure PRNG), then there is no need for salts or iterations; just use a plain hash function (even MD5 would be fine there). This will be more efficient.

As for using a random authentication token instead of login+password for each request, there are two main reasons for that:

Performance: as explained above, an authentication token can be verified safely with a simple hash, which will be vastly more efficient than a heavy bcrypt call. You want to keep your precious CPU cycles for when they are really useful, in particular when applying bcrypt to an actual human-managed password.
Client-side storage: the authentication token will be stored on the client as a cookie value. If the login and password are sent back with every request, then they are stored as a cookie on the client. People get nervous when their passwords are written to files -- and such storage is not equivalent (from a security point of view) to the storage of an authentication token, because human user are on the (bad) habit of reusing their passwords for multiple systems, whereas authentication tokens are inherently server-specific.


criminals can change these IMEI numbers in order to regain access to a
  network.

Not only criminals, changing IMEI is easy even without root access, there are plethora of apps that can do just that.

  How is this done and what can I do to protect myself from it?

For most devices, IMEI is stored in EEPROM, simply raising a voltage from normal working one will allow you to change whatever is stored on it.

You mostly can't do anything to protect only IMEI. Hardware limitations. However, you can for example encrypt your phone internal storage, set a startup code, enable device locator and so on. This will make it harder for criminal who stole your device to actually profit from it.

Unfortunately, not all phone models support that (startup encryption)