Sending and blocking emails from hashed and salted address ? (for GDPR)

You might be over-thinking the problem. In order to record consent, you need to store the PII. It is ok that it is stored un-hashed.
You appear to want to hash the emails as a layer of protection, but I would rather that a service spends time protecting access to this stored information. If an attacker can get access to the hashed emails, then you can assume that they also have access to the salt, and access to other data that would allow the attacker to guess or test emails. So, I'm not sure if hashing will ultimately do any good.
What big services do is to restrict access to the data.


How harmful is it to expose access token to the resource owner?

It is true that bearer tokens and session tokens should not be passed int he url. The reasons are (according to OWASP):

  might disclose the session ID (in web links and logs, web browser history and bookmarks, the Referer header or search engines)

In this specific case, I think Facebook did not care since the usage is logout - so after it has been called the token is not usable anymore any way, so no big deal if it is leaked.


How good using hash value of size 32 bit in practice

You are mixing two different concepts into one.
Consider two things:  Is the hash to check for integrity for data due to interference that is not likely to have been tampered with?  Or is it for security?
A TCP packet has a checksum (like a hash), for purposes of determining if interference changed part of the packet.
Security hashes, and even file integrity hashes, started with 128 bits, and now are in the 256-512 bit range.  32-bits cannot be considered for any type of secure application, including a digital signature.
A digital signature with a 32-bit key and 32-bit hash is only a little bit better than ROT13 and maybe worse as it might give a false sense of security.


Ouath2 how does it work (Android client)

To your questions:

  [...] I don't have ability for user to login with social network accounts
  and other Oauth2 servers in the network [...].

You will need your own OAuth authorisation server, that will manage your resource server.
The OAuth server from Google, Facebook, Twitter, etc., will not help because, as far as I know, can only grant access to their own resources such as email, photos, posts, etc.

An example would be:

You need a picture for your service.
You want the one an other site is using.
You get authorised by the owner of the picture (typical the user).
With the token you now can access the picture.

I think you understand the protocol flow, but probably mix up Authentication(verify ones identity) and Authorisation(grant access to resources).

OAuth v2.0 is an authorisation protocol, it will manage the access to resources. To make it possible for other services (this could be your app) to access your resource server data.


Hacked Router Faking a Certificate Authority

I assume your question was:

  Does a computer ship with CA certificates preinstalled?

This is the case.

The standard OEM installation of Windows (and all other OS) on a computer ships with a preinstalled list of trusted certificates.

Here are the lists for Windows and
iOS.

Even if you had CA certificates in your store that were preinstalled, they don't come there from nowhere. Windows updates the preinstalled list through Windows Updater. The connection to microsoft is also encrypted, so that you can trust the updates to be from microsoft.


Hardware compatibility with Hashcat in Windows 10 (64-bit)

I don't have a lot of great news for you, but I do have a couple of pointers.

On the Intel side, as noted in the output, the Intel OpenCL drivers have a known problem with hashcat that must be resolved by Intel. There's not a lot you can do about that part.

On the AMD side, I think that the device that's actually active in your test run - the AMD Hainan - is a Radeon 8800 or similar? If so, it's pretty old, and probably not likely to perform very well. You'd be better off renting an AWS GPU instance.

You might also try -d 4 to explicitly try the AMD driver for your CPU to see how it performs. It might actually be faster than your AMD GPU.

Once you've got your platform established, adding a couple of options should help:

-O (use optimized kernels, since your target mask is short)
-w 4 (highest workload factor)

But that's about all you can do with the platform you have. There are no driver changes that are going to significantly help that I'm aware of.


Is it possible to recover securely deleted data from a hard drive using forensics?

Your question has a problem with the definitions of the words in it.

If a HDD has been securely wiped, by definition, no recovery is possible. If a HDD has not been securely wiped, by definition, recovery is possible.

Perhaps you mean: How secure are various methods of wiping Hard Drives? Very secure, assuming you're talking about "traditional" drives (with magnetic spinning platters) and you use something reputable like Darik's Boot And Nuke (aka DBAN).

There is some concern about how to securely erase Solid State Drives, because the drives have a built in ability to evenly (and transparently) distribute read and write operations across its entire memory space. This is done to increase lifespan of the drive, but can frustrate secure erase operations.


Rootkits, Bootkits detection and protection and Firmware alteration

If attackers had administrator/system/root level privileges on your computer, they have a lot of possibilities to permanently backdoor your computer. Not many attackers can do this kind of persistence, but it is possible.

MBR bootkit - can be cleaned via formatting from live cd
BIOS/UEFI malware - see Computrace rootkit
HDD firmware - GrayFish malware
GPU/Ethernet/other firmware modification
Hardware implants

The best solution is to box all of your devices which has more than 0% chance of infection (and label the box with something like "infected, don't use"), and buy a new computer and a new phone - but don't order it to your home, go and buy one in a random local store. And don't trust any of your old data from old backups. Based on your paranoid level, not even image, music, video files can be trusted - but it is 99% they are safe. MS Office documents can be a risk more likely.

I believe the same attacks are more or less possible on Android devices, but there are no known cases of these - at least I know of. I think the easiest backdoor would be to replace the bootloader.

Detecting such intrusive rootkits are hard. There is no simple way to check for rootkits. The easiest way to do this is to disable the services on your computer which communicate with the internet until nothing should communicate, and run tcpdump on your router for days. After that, analyse the traffic and look for unknown IPs/domains. Meanwhile, check for side channel leaks like WiFi or Bluetooth. Most rootkits can be found via this method. Creating fake activity (e.g. typing in a text editor, generating new fake PGP keys) might help trigger the bad traffic.
When it comes to rootkit detection on Windows, my personal experience is that GMER can find most rootkits - but not all.


You could

ask the person who set up the VPN what exactly it is (PPTP? L2TP? etc)
use tcmdump (or wireshark on windows) to see what IP protocols and TCP/UDP ports are used to setup the VPN connection

or ... simply disable both, and see which one you need to enable to have the VPN go through.


With PBKDF2, what is an optimal Hash size in bytes? What about the size of the salt?

For the hash function, you want to use a function for which the most efficient platform type (the one which will produce the more hash computations per second and per dollar) is the machine that you intend to use (i.e. a PC). That's because you are in a weapon race with the attacker, and the attacker can buy other kinds of hardware to get an edge over you (such as a GPU). GPU are very good at 32-bit arithmetics, but not at 64-bit arithmetics, whereas a PC (in 64-bit mode) will be quite fast at the latter.

Thus, use a hash function which runs on 64-bit arithmetic operations. This points at SHA-512.

PBKDF2 is a key derivation function: it produces an output of configurable size. For password hashing, you want the size to be large enough to deter generic preimage attacks (i.e. trying random passwords until a match is found), so this would need, say, at least 80 bits of output. If only for making the security more convincing for the unwary, and also for aesthetics, go for the next power of 2: a 128-bit output. It is not useful to go beyond that.

The salt must be unique -- as unique as possible. An easy way to achieve unique salt values is to generate salts with a cryptographically strong PRNG: probability of reusing a salt value will be sufficiently low to be neglected if these random salts are large enough, and "large enough" means "128 bits". So use random 128-bit salts.

Personally, I prefer bcrypt over PBKDF2 for password hashing.


Do account recovery options defeat stronger 2-factor authentication?

It certainly can be! When designing such a system, you need to keep in mind that the Account Recovery mechanism will reduce a 2FA system to a 1FA system, so the Account Recovery mechanism needs to be held to the same (or higher) standard than the 2FA method.

Depending on the security policy of your organization, the following would probably be acceptable as "2FA Method <= Recovery Method":

2FA Method: None. Recovery Method: question & answer.
2FA Method: SMS / email OTP. Recovery Method: email password reset link.
2FA Method: OTP app. Recovery Method: recovery codes that you printed during setup.
2FA Method: OTP token or yubikey. Recovery Method: contact your administrator.

If answering "Name of your first pet?" was enough to get into account settings and disable a Yubikey, that would be a vulnerability worth reporting for sure.


What is the difference between APSA and APSB?

Adobe Product Security Bulletin (APSB): An announcement about a security vulnerability in an Adobe product. The vulnerability has been patched, and the solution is to update to a newer version of the product.
Adobe Product Security Advisory (APSA): Same as APSB, except that the vulnerability has not been patched yet, and a fix update isn't available yet. A solution is either to downgrade to a safe version, using other mitigation methods, or that there's no current solution.


Are there any risks associated with importing metadata?

Absolutely. For example, it is a fairly well-known trick to embed XSS attacks in JPEG EXIF data. Here's some very simple example code that's exploitable with a corresponding image: https://github.com/vjex/Exif-XSS


Purpose of hash verification of file served over HTTPS?

HTTPS protects file against modification during transmission. But, HTTPS does not protect against file corruption in all cases: if the transmission is aborted early or of the server has problems in transmitting the file you will not notice. In these cases a checksum might help. Also, in case the download site is just a mirror of another site provides both file and checksum makes it possible to detect errors during the mirror process.


Secure way to log in to a website on someone else's computer

This is an interesting question!

The rule of thumb is that if someone else has control of the device (and they're determined enough), they will always be able to monitor and modify all of your actions on the device.

We can (to a somewhat limited extent) get around this though! Two-factor authentication can be used to ensure that even if someone has your password, they cannot get into your account without also having access to a separate device (owned and controlled by you).

Keep in mind that once you log in, the computer ultimately has control over your interaction with the website, and as a result it could trivially see everything you do on the site and even modify your requests to the site (including not logging you out properly when you're done, and potentially changing your login details to lock you out of your own account).

This all depends on how worried you are about being attacked - if you're just logging into Facebook on a friends computer, you can probably trust that when you hit "Log Out", it actually logs you out. If you're logging into something really important, however, you may want to stick to devices you control.

Additionally, consider the following, via user TemporalWolf

  Some websites allow for the generation of single-use one time passwords which sidesteps any sort of password logging... as you mentioned, this doesn't stop them from mucking with the now authenticated session.


Securely expose WebService from Enterprise Network to Internet Client

Whilst the answer given by AaronS gets to the gist of it (rather harshly if I may say so), I think the general principle that applies to any secure solution is defence-in-depth. That is, using several layers of security to prevent against attack, compromise or data leakage.

I'm not going to go into the debate of what percentage of attacks/leaks are internal, but whatever it is, this should not be forgotten or ignored either. You might follow AaronS's suggestion and 'never open your LAN to the internet' and put the server on the DMZ, and an employee might still be able to dump your database onto a memory stick and walk out the door with it.

So if you're looking for buzzwords, I would start with making sure you have network protection (e.g. Firewall, Intrusion Detection/Prevention) in place first, apply all the necessary patches and updates to your software and OS (Hardening). Use network segregation to separate your applications so that data flow is tightly controlled (DMZ is one common example, but other network segmentation models also work). Make sure the web service is developed securely, tested and code reviewed. Even with the best firewall and DMZ in the world, if the application itself is vulnerable, then most of this protection might have limited effect. Since the external facing web service will likely consume data or communicate somehow with internal components, make sure the same methodologies apply to them too. Make sure Authentication and Authorization are used to control access to data. Make sure you have solid monitoring and logging in place... The list goes on. This is by no means a substitute to a proper security architecture / analysis, which the security people in your organisation should be able to perform.

As for the 'high security proxy' you were asking about - there are a few products that provide application layer protection, see Application Firewall on Wikipedia. Those can also be added to the mix, but I would not rely solely on these for your security.


ssh into a server with knowledge of ca bundle

Did you give them any private keys?
If so, maybe, depending on how your service is set up. You need to immediately revoke the certificates for those keys, and replace the private keys (and certs) with new ones on all your servers.
If not... no. Public keys are, after all, public. Certificates only contain public keys (and some non-key data) and are also public.


Let's say an attacker wants to get a user to click something on victim.com.

For this, they need to place an iframe somewhere - anywhere - where the victim will see it. It doesn't really matter where it is placed, or how it was placed there.

This is not required, but ideally, the attacker can also run JavaScript here, as it increases the chance of successful exploitation, especially with multi-click attacks (it is possible to "follow" the mouse pointer and thus make sure that any click clicks on the desired position of the victim.com website).

These are the ways that I can think of that an attacker can deliver an iframe to a victim:

The attacker hijacks a website, good.com, they know their victim will visit. This may happen in different ways; the website may allow the creating of iframes, or the attacker may have compromised the server
The attacker creates their own website, evil.com, places their ClickJacking payload on it, and gets the victim to visit it by sending them a link.
Email: Some email clients may display (a subset of) HTML code (this is really only a subcategory of the first point though)
The attacker may be able to place an iframe on victim.com. If this is the case, the problem likely extends beyond ClickJacking (at least HTML injection, likely XSS).
The attacker may be able to change the delivered HTML in transfer (mitm) or on the client side and thus inject an iframe. But again, if this is possible, there are far greater consequences than ClickJacking.

Here is a very simple example of how a ClickJacking payload might look:

// placed anywhere, eg http://evil.com/clickjacking.html
<div style="position: absolute; left: 50px; top: 50px; pointer-events: none;">
    Click Me!
</div>
<iframe style="opacity: 0;" height="500" width="600" scrolling="no" src="http://victim.com/vulnerable.html>
</iframe>

So it is not necessary that an attacker changes the HTML of victim.com (not at the source, nor at the client side).


Do CSPRNGs have a maximum input seed length to output length ratio?

This is exactly what /dev/urandom does, actually.

A PRNG with a seed of length N bits will have a period (repetition length) of 2^N bits, due to the pigeonhole principle. So as long as your CSPRNG is perfectly secure and has a seed length of, say, 256 bits, you don't have to worry about ever repeating before the heat death of the universe. (Note that seeds are of fixed lengths.)

The reason this is considered dangerous is because if for any reason your PRNG leaks state, say because an attacker uses a kernel info-disclosure bug, all the "random" data is compromised until the next reseed. OTOH, fetching "real" randomness when you need it provides perfect forward security.


The most systematic answer is to implement split horizon DNS in your infrastructure, such that only internal addresses resolve; clients then must use a proxy server to connect out to the internet, and the proxy server resolves external DNS for them. This is particularly effective if your core network doesn't have a default route, so that packets destined outside your network are dropped.

The downside, obviously, is that retrofitting those controls into a running environment is likely to be an expensive and complex proposition...


How to send cookie to API on seperate domain in safari

When cookie A is set by api.myapp.com while the origin of the request is theirapp.com, then cookie A is treated as a third party cookie. Third party cookies were allowed by browsers until recently. Safari announced all third party cookies will be blocked by default. Both Firefox and Google will follow soon.

The suggestion from the said post which likely applies in your case is to use OAuth 2.0 authorisation. Or you could use OpenID connect (which is based on OAuth 2.0).


Are RESTful sites safe against CSRF attacks?

Same-origin policy doesn't allow to JavaScript or similar receive response of sent requests outside your host !

  In computing, the same-origin policy is an important security concept for a number of browser-side programming languages, such as JavaScript. The policy permits scripts running on pages originating from the same site – a combination of scheme, hostname, and port number1 – to access each other's methods and properties with no specific restrictions, but prevents access to most methods and properties across pages on different sites.1 Same-origin policy also applies to XMLHttpRequest and to robots.txt.

Your application is Ajax but it can be vulnerable to CSRF (if you don't check content-type or adding unsafe Same-origin policies).

If you don't check content-type, attacker can send this request with normal form, like this :

<form name="x" action="http://site/index" enctype="text/plain" method="post">
  <input type="hidden" name='{"fname":"abe","lname":"m","company":"comp","email":"abe@test.com","Junk":"' value='Noting"}'>
</form>
<script>document.x.submit();</script>


Apparmor profile denying read access with r flag

Did you both reload AppArmor and restart the application? Simply reloading AppArmor does not mean changes to the policy will take effect immediately. If that does not work, you can whitelist the entirety of /usr/share/tor. It is only writable by root, so there is no issue with malicious programs modifying it, and it does not contain any sensitive information. It is not writable, so you wouldn't benefit from more fine-grained control over it. Simply letting Tor read anything inside it is perfectly safe:
/usr/share/tor/ r,
/usr/share/tor/** r,

As for /proc/sys/kernel/random/uuid, it is not sensitive. All it does is return random data formatted as a UUID. It provides no more information than /dev/urandom does. From proc(5):
/proc/sys/kernel/random/uuid (since Linux 2.4)
    Each read from this read-only file returns a randomly generated
    128-bit UUID, as a string in the standard UUID format.


Using HTTP GET instead of a POST request can leak source code?

However, if a GET request is sent for a webpage to the server, then the server does not execute the server-side code - it simply returns index.php to the end user leaking the server-side code.

Your assumption is wrong. A GET or POST does not change anything related to sourcecode leak. They are processed the same way, and the result will usually be HTML being sent back.

Main differences between POST and GET:

A GET request will show fully in the address bar, and a POST does not

Bookmarking a GET request with a password will also record the password, and a POST will not.
A GET request gets written fully on webserver logs, a POST generally not

If someone reads the logs of the webserver, all info of all requests can be read from a GET, but not from a POST

Using POST will make slightly harder to someone to conduct a CSRF attack against your site. But have absolutely nothing to do with a source leak.


In practice, unless each mobile contributes bandwidth and storage space to the P2P network, a P2P network will involve computers other than the mobile applications of your use case. And thus susceptible to a security topology beyond your control.

If the network is pure P2P (no central servers other than peer discovery bootstrap) and it is restricted to the mobile application only, then these peers can block external access by encrypting connection and communication with an asymmetric key pair only stored within the mobile application. This is in additional to any other layers of encryption the communication may choose to have or not have.

Of course the application can be reverse engineered to steal the key; so it depends on how motivated people who acquire a copy of your application are to do this. Alternately the network can be little less "pure" P2P and periodically update the global application key pair from a server under your control.

So, security assessment:

If the P2P network is yours, you can protect it from most security problems. Perhaps even making it a DarkNet to reduce visibility to DoS attack.
Or if your application uses a P2P network that isn't yours in order to avoid the mobiles having to contribute bandwidth/storage/cpu relative to network size - then security of the P2P network will mostly depend on the specific design trade-offs of that network. You would need to provide the exact existing P2P network for review in that case.


I find two possible flaws.

UUIDs in general do not guarantee to be cryptographic random. Depending on implementation it may be possible to give a qualified guess about what other UUIDs have been generated by a generator, given some of the output. You need to use a suitable length of output from a cryptographic random number generator as session token.

Whenever you extend to a web client you need to secure against cross site request forgery, that is, any request that change data on the server needs to have a token that is not a cookie as part of the request, otherwise the request can come from another open web site on the users computer.

Another thing, if you want to reduce stress on the DB, you can store session information in process memory in Node. You only need the database for things that has to persist through a crash.


What are eligible service providers for SAQ-D in PCI DSS?

Only Level 2 Service Providers are eligible to use the Self-Assessment Questionnaire.  As PCI Policy Portal summarizes, these are defined as:

  [Level 2] Service Provider Criteria for VISA: Any service provider that stores, processes and/or transmits less than 300,000 Visa
  transactions annually.
  [Level 2] Service Provider Criteria for MasterCard: (1). Includes all DSE’s that store, transmit, or process less than 300,000 total
  combined MasterCard and Maestro transactions annually.

Additionally, American Express defines Level 2 Service Providers as "less than 2.5 million American Express Card Transactions per year; or any Service Provider not deemed Level 1 by American Express."

In practice, you will rarely see a Service Provider - even a Level 2 - using an SAQ. They don't get a heck of a lot of respect out of QSAs, and QSAs are the ones deciding how hard to look at a given merchants' chosen Service Providers.


Is there a protocol for securely trading information between possibly uncooperating agents?

The answer is no, and it's explained why in the Thomas Pornin answer to another question.

From any system that doesn't require a trusted third party, there's no way to escape, since you can force them to reveal the secret at the same time. So, no matter if you encrypt it, sign it, say it louder, everybody types at the same time in a chat, reveal some hash first, etc., if you're not obliged to reveal the information, you simply don't reveal it, loses nothing, and earn information provided previously.

Publishing hashes before might only assure that the revealed information wasn't changed between the time it was "written" and had the hash calculate, and the time it was really revealed. So you solve the "alter the answer" part, not the "refuse to answer" one.


One Time Passwords. Using OTP at Windows, Ubuntu and internet sites

OPIE Authentication System ("One time Passwords In Everything") works on most any BSD/Linux/Unix system - e.g. opie-server and opie-client packages under Ubuntu.  It can be used e.g. in PAM authentication or for web servers.  There are clients (at least) for Windows and MacOS also.

If a site is a "relying party" for some sort of federated authentication (e.g. OAuth, OpenID, Shibboleth, SAML) you can use OTP once to log in to an identity provider that supports it, and use what are essentially one-time credentials from them to log in to the site.


Password security - how much do non-alphanumeric characters matter?

There are two factors here.

Firstly, you are correct, the entropy is the same. What is important is the address space not the utilisation of that space. So as long as users can use symbols etc, that's what's important in the first instance.

However, the second factor is guessability or breakability. Can a password be guessed using rainbow tables? Can a password be brute-forced (e.g. all characters the same). Your example of 123456789012 falls foul of this since it will certainly be in any decent rainbow table because it is simple and common.

So current best practice for passwords is that you allow extended characters but you don't enforce specific rules (which in any case reduce the address space). You encourage longer passcodes - "codes" note, removing the emphasis on "words" - good passcodes may be memorable but are not guessable. And finally, because you are encouraging complexity, you wouldn't be enforcing 30, 60 or even 90d passcode changes. At least for individual ID's, shared/admin ID's may be a little different.

My feeling is that this approach is a good balance of usability and enhanced security. But I think that you should ideally audit passcode databases periodically to hunt down weak passcodes.


Why is credit card information not stolen more often?

PCI DSS

The major reason for this is a decade long effort by the payment cards industry to limit the extent of such breaches by requiring everyone who handles payment card data to either (a) conform to a set of security practices and (usually) audit requirements, or (b) stop handling payment card data themselves and delegate it to someone who can handle this better.

You shouldn't underestimate the second part - while pretty much all sites handle their own user account data, the vast majority of sites (especially smaller ones) that accept credit card payments do not store credit card data in any way whatsoever; if they do want recurring payments without asking CC number every time, they instead store 'just enough' information to show the user (e.g. a partial card number) that this card is "remembered" plus a token issued by their bank/gateway/whatever that enables additional payments from this card to the same merchant - so these tokens are useless to an attacker.

While it's not 100% proof and there are many, many cases where PCI DSS is blatantly violated, it does mean a significant reduction in the number of vulnerable companies.


Why should I have secure passwords for sites that I pay bills on?

The most significant potential risk that I see is that profile information on these sorts of sites could potentially be quite useful for pivoting into identity theft.  If there is stored financial information visible (like the last four digits of your credit card number, for instance) this has been shown to be useful in helping attackers own additional accounts you have elsewhere that they want, but don't have credentials for.

Beyond that, it's hard to say what someone might do, but the risk is probably low, and you'll have to gauge for yourself whether it's acceptable or not.


Is the lack of an IP address in the AN field of an SSL certificate a vulnerability?

Would this be considered a low risk vulnerability?

Yes.

  If an attacker can force the use of an IP address, then surely the
  certificate is no longer of any value at this point (unless installed
  on a client machine)?

I'm not quite sure I understand the question. Even if an IP address is forced by an attacker and the IP address is not defined as a SAN, the traffic will still be encrypted.

However, keep in mind that RFC 6125 recommends against strictly using an IP address as the defined name:

  Some certification authorities issue server certificates based on
        IP addresses, but preliminary evidence indicates that such
        certificates are a very small percentage (less than 1%) of issued
        certificates.  Furthermore, IP addresses are not necessarily
        reliable identifiers for application services because of the
        existence of private internets [PRIVATE], host mobility, multiple
        interfaces on a given host, Network Address Translators (NATs)
        resulting in different addresses for a host from different
        locations on the network, the practice of grouping many hosts
        together behind a single IP address, etc.  Most fundamentally,
        most users find DNS domain names much easier to work with than IP
        addresses, which is why the domain name system was designed in the
        first place.  We prefer to define best practices for the much more
        common use case and not to complicate the rules in this
        specification.

UPDATE:

It seems that Symantec, along with several other CA's will no longer issue certificates without a valid FQDN.

  For this reason, the leading Certification Authorities, including Symantec, that make up the Certification Authority/Browser Forum (CA/B Forum) have decided to cease issuing certificates without a Fully Qualified Domain Name (FQDN).

Please reference: http://www.symantec.com/connect/blogs/important-changes-ssl-certificates-intranets-what-you-need-know


Security of using DHCP and non-standard ports for medical devices

Can some explain why DHCP and non-standard ports are considered so risky?

I don't think that this was claimed. I think instead that the quote was taken too much out of context which lead to a misinterpretation. The relevant context for this quote was

  Two major factors made the filtering process challenging....

Thus, this paragraph does not talk at all about the security of DHCP or non-standard ports as assumed in the question. Instead it argues that these mechanisms made it harder to collect and filter the information necessary to evaluate the security of the systems: If a device is using typical ports it is easier to use a system like Shodan to find exposed devices than if the device uses atypical and thus unknown ports for the communication. And if it is harder to detect problems it also means that there might be in reality more problems than were detected.


The extension injects the Ethereum web3 API into every website's javascript context, so that dapps can read from the blockchain.

Because it adds functionality to the normal browser context, MetaMask requires the permission to read and write to any webpage.

Like many Chrome extensions, metamask works by adding extra JavaScript to every page you visit. The metamask script has access to everything that happens to every loaded page. It could record keys and form inputs and transmit that, or read your password or session token and take over your account.
However, it still runs somewhat sandboxed, so it is limited to the browser. It can't sniff your network interface, or read a local file. Keylogging is limited to keys entered within the browser.
Even if the plugin itself is not malicious, it could contain a vulnerability that could then be exploited by any page on the internet you visit.
So browser plugins are fairly powerful. Chrome and Mozilla do some checks before adding extensions to their app repositories, but that does not provide guarantees.


How to secure sensitive information on cloud from administrator (end-to-end encryption)

If you are a user of a system and other people have administrative access then, realistically there is little, if anything, that you can do to stop them gaining access to the information you process on that machine.

They are likely to have the power to install software on the machine, so could (theoretically) install key loggers or other types of software which monitors your activities and gives access to data you process on the system.  This, of course, is not to say that any company will actually do this, just that they can, and when you're considering the security of your personal information, you need to assume they will.

From their perspective, this kind of access may well be necessary for them to ensure the security of the device and ensure that it is not being mis-used.

If you have information that you want to access or use without that risk, then you need to have a system that only you are the administrator of.  So in a work scenario, use a personal smartphone, tablet or laptop to work on the items that you don't want to be visible to your employers.


OAuth 2 Implicit grant type for first party SPA - Most secure and sensible way

In your case, I think that OAuth 2 doesn't make sense. It's designed to handle third-party clients, and the additional complexity is likely to be a distraction when you only have one single first-party client.

For user security:

No matter what you do, a web-based app is one where the user has to trust some webpage of yours with their username/password. For this reason, it seems sensible to just directly username+password authentication and skip OAuth 2, unless you have some other reason to use OAuth 2.
For publicly-visible resources, allowing access without authentication should be fine.

For securing your API to be used only by your SPA:

This is a completely different issue than user sign-in, and I'd recommend not getting sidetracked by how to acquire access tokens. For instance, many SPAs can be trivially modified/decompiled/spoofed.


Is it dangerous to serve unescaped user input as HTML response to the same user?

You definitely shouldn't do it. Why do it wrong if it is so easy to do right? You should have mechanisms in place that automatically HTML encode all output variables (which will catch most but not all XSS issues); If you have to consider the dangers for each and every output, you will make a mistake at some point.

XSS in a user area can still be exploited if other vulnerabilities exist as well, either by using CSRF or by placing the XSS payload into an account the attacker controls and then forcefully logging the victim into that account (via Login CSRF, Session Fixation, or various other vulnerabilities).

Reflected XSS in a user area may also still be exploited via CSRF, or possibly via ClickJacking, if the browser allows drag/drop into a frame. Depending on the application, there may also be further corner-cases which allow an exploitation of this issue.


Known examples of spoofed Change Request?

Usually Change Requests Workflows have well-defined steps, e.g.:

Plan: Implementor create the Change Request Ticket and fill it with the implementation details (scripts or whatever technical information is needed to fully implement the change)

Discussion and 1st level approval: A technical committee analyzes the proposed change and approve or request it to be re-planned. After this step is impossible to change the contents of the proposed change.

Final Approval: The pre-approved requests are send to a second committee, this time the customer is directly approving the proposed changes.

Implementation: The approved change is implemented and evidence is collected.

Revision and closure: The evidence of the change is reviewed and finally the change is closed.

This cycle would prevent someone tampering with a request due to several opportunities to spot it (either before and after the implementation)


With openssl des3, what are the passphrase parameters?

"openssl des3" is really "openssl enc -des3". The password-based key derivation is a custom, undocumented scheme which, as far as password-based key derivation schemes go, is quite weak; see this answer (especially at the end) for some details. Basically, this is equivalent to hashing the password with a couple of MD5 invocations.

What matters for passwords is entropy, i.e. not the password length or the type of characters used; entropy is a measure of what the password could have been. See this answer for details on how to compute entropy. Remember that entropy is not computed on the password itself, but by analysing the process that generated the password.

Since the key derivation scheme used by OpenSSL is quite bad, you need a lot of password entropy to achieve decent security. As a rule of thumb, the limit of computational power of serious attackers is 280 invocations of a cryptographic primitive like MD5 (rich attackers like the NSA would have much trouble reaching such computational levels; even very rich organizations like Google or Apple would find it quite challenging, and would not be able to do it discreetly). In this case, since trying a password means roughly computing two MD5, this means that the password entropy should exceed 279 -- i.e. "79 bits" because entropy (in cryptography) is normally expressed in bits (which is a logarithmic scale).

IF you generate your passphrase as a sequence of random characters in a given alphabet, with each character being selected randomly, uniformly, and (crucially) independently of the other passphrase characters, THEN entropy can be easily computed: if you use n lowercase letters (26 choices for each character), then entropy is 26n. With n = 17 (17 random lowercase letters), then entropy is close to 280, i.e. 80 bits, which, as explained above, should be sufficient. Even a small character set can be compensated for by using a long-enough passphrase, because what really matters is the entropy, not the length or the kind of character.

If you try to generate passphrases that "make sense" in some way for a human, then entropy is a lot more difficult to compute, because human psychology is very bad at randomness. Again, see the answer on entropy computation.


Using Dropbox is not inherently a greater security risk than other methods of data transfer.  I work at a security consulting firm and we often use Dropbox to move encrypted archives to our clients.  We also use SFTP,  but this seems to be problematic for some of our clients.

A better policy is that all company data must be encrypted at rest.  This policy should include company laptops, servers, cloud services and anywhere else you maybe storing company data.  Make sure you educate your employees about storing and transferring data in a secure manner.  Blocking Dropbox may have adverse effects,  such as forcing employees to use less secure methods of transferring data.  I have found that employees will find creative ways of doing their job,  and its not always secure.


Possible to verify someone is a real person without direct connection?

You're describing the setting of a "prisoner's dilemma" type game, which is based on a situation where trust between prisoners cannot be established.

The normal ways of establishing trust would be as you listed; to meet personally and exchange keys, or to employ a trusted third party, such as a Certificate Authority or WoT, to facilitate trusted key exchange.  In every case, though, participants need to have trust externally introduced without going through the M proxy, or with the third party's certificate pre-installed (all of which still depend on M not being the party who provided the machines in the first place, and M not having surreptitious access to the machines.)


Windows Automated Explicit Logon Rule to detect Lateral movement

I think you are right, you'd want to log some of these all the time. 7045 seems to jump out to me. In comparison, this is the splunk rule:

index=windows   LogName=System  EventCode=7045  NOT
(Service_Name=tenable_mw_scan)  |   eval
Message=split(Message,".")  |   eval
Short_Message=mvindex(Message,0)
|   table   _Ome    host    Service_Name,   Service_Type,   Service_Start_Type,
Service_Account,    Short_Message

reference: https://conf.splunk.com/session/2015/conf2015_MGough_MalwareArchaelogy_SecurityCompliance_FindingAdvnacedAttacksAnd.pdf


What can hacker do, if he knows my SALTED password?

First of all: the salted hash generally contains only the password, not the username, but they are commonly nearly stored.

He will then be able to launch an offline Brute force attack, trying to find the password that generates that same hash using that same salt.

This attempt may be dictionary-based or exhaustion search-based.

Also, to be allowed access, one MUST have possession of at least 3 pieces of information:

Address (in this case, FTP's address)
Username
Password

If he already has the ftp address and the password, he still has to discover the username. It is possible to use the same technique to make several attempts until he finds a  username that uses the known password in its credential.

The usage of SALTING only prevents other accounts with the same password from having the same hash, what would promptly alert the hacker about users sharing the same password.


Why might I want to remove the wlwmanifest.xml file in WordPress?

There's no point in removing it. It's a static file with information on how Windows Live Writer can talk to wordpress.

Discovering that you're running wordpress is usually rather trivial, so nothing much is revealed by this file either.

When it comes to securing WP, focus on staying up to date, via automatic patching.


Can JWT authentication act as an anti-CSRF mechanism?

If the JWT is in a header, you should be safe. The attacker can't fool the victims browser into setting the header (unless CORS allow it, or she leverages an old Flash exploit). But lets say the attacker can control the header. Then what should she set it to? She wouldn't know.

On the other hand, if the JWT is in a cookie you will be just as vulnerable as with an ordinary session cookie. So wheater you are vulnerable or not has little to do with what kind of token you use (JWT or session ID) but more to do with where you put it (header or cookie).

Even when the authentication comes with automagic CSRF protection, you may want to consider adding a explicit CSRF protection anyway. There is always a risk that someone changes the authentication mechanism without realising it has double purposes.


Hiding remote database credentials in application

You don't try to hide them. Anyone with access to the application and sufficient incentive will be able to find the credentials.

So what do you do instead? It all depends on what you're trying to restrict. If it's an app for anyone to download and use then you may not need any credentials. A step up from that would be to generate and store a security token after the enduser enters any required data (ie. registers). Or you can have the end user enter credentials that have been assigned to them (eg. a user name and password). The point is that each user/device gets a unique identifier that can be revoked if needed and if found by the user doesn't give them access to anything beyond what they already have access to through the app.

The reason using POST and GET are suggested is less about the authentication process and more about limiting and controlling what it is that the app can do. With a REST (or similar) interface you can program various validations of the data coming from the app and you can do it on a piece of hardware (the server) where you have full control. Using an interface like that also means you don't have to open up full access to the database as you would only program the functions your application actually needs.


Is it good to split file into chunks to be more secure in the cloud?

You could split the file into parts, and probably be a little bit safer. But the usability loss v. security gain trade off isn't very good.

With good crypto (such as AES) on the client there isn't really any need for that. Focus instead on keeping your key random and secret, and the system that does the encryption secure. Those are your weak points.


http://www.adambarth.com/papers/2009/barth-caballero-song.pdf is a excellent overview reference of the problem. It is not only for images, also for txt files and others...


What is the point in having arbitrary username requirements?

There are two main arguments for enforcing requirements/restrictions on username choices.  The first is that making usernames more difficult for attackers to predict helps resist online guessing attacks.  While usernames aren't necessarily considered to be as secret as passwords they are one of at least two pieces of information that must be stolen to impersonate a user.  We shouldn't dismiss the advantage of this information remaining unknown to attackers.

The 2007 paper Do Strong Web Passwords Accomplish Anything? (PDF) evaluates the threat of online password guessing and considers the what our options are to combat it.  A site can enforce a stricter password policy which may hurt usability if users struggle to comply and experience frustration with the process.  Or the site can enforce some username restrictions and keep the password policy the same.  Their theory being that if an attacker has to try a lot of possible combinations it doesn't matter as much whether that's due to easy usernames and complicated passwords, or semi-complicated usernames and semi-complicated passwords.

This ignores a third option of the site adding a second authentication factor to supplement the security of a password while leaving usernames alone.  It also requires the site to work harder to avoid disclosing valid usernames that attackers can then pair up with possible passwords.

The second argument is that by enforcing somewhat unique username requirements a site can hope to deter users from choosing the same credentials they've used on other sites.  This is a very real threat and it's a difficult one for a site to do anything about besides enforcing unusual usernames requirements (or assigning IDs themselves).  However, one awesome study from 2010 monitored actual username and password reuse by people between their banks and other sites.  The study found that people did indeed reuse their bank password on other sites 73% of the time, but also found that even if a bank enforced unique username conventions people would then reuse that username on at least one other site 42% of the time.

So enforcing unique username requirements lowered the chances of credential sharing, but certainly didn't eliminate that possibility.  But that lower risk may still be seen by some sites as worth the inconvenience to users.

Another possible reason, that's less of an argument and more of a requirement, is legacy system compatibility.  Whatever potentially old software is doing back end processing behind the snazzy web front end may have been coded to only accept usernames formatted a certain way.  Without ripping out and replacing that software the site may be stuck passing on the restriction to customers.  The 'User IDs cannot begin with an X' line leads me to believe this may be a factor in your case.


Two Step Authentication - Email versus Text Message versus Phone Call

Are you in Canada or something?  Multi factor authentication has been required in the United States since 2006 for all banks.

Any out of bank authentication (email, SMS, and voice) is fine and are roughly equal.  The codes they use are single use and expire within a short amount of time so there is no black market on which hackers can sell them.

If I were forced to rank them from least secure to most secure, I would list them as

Email - Probably the easiest to intercept
SMS - Could be recovered from your inbox somehow, I suppose
Voice - Only works in real time and requires a human being to listen to it


Disclosure: I work for AV vendor.

The answer depends on whether you are talking about:

Anti-malware engine which scans content without executing it. This is what people call "scanning a file", and what is used, for example, by VirusTotal;
Anti-malware engine which detects malware by monitoring running processes for malicious activity (this is often called "behavior analysis").

For the first one, with exception of Symantec, which reportedly runs parts of antivurus engine in kernel, I don't know of any other vendor whose anti-malware engine runs in kernel. Even for Symantec it was matter of choice and not the requirement, as the anti-malware engine has the same detection when running in userspace. Kernel module is required to intercept events (such as file access), but the accessed file name is typically passed to userspace and scanned there; there are no requirements to scan it in kernel.

For the second one, while this engine is usually also implemented mostly in userspace, it depends a lot on its  sensors implemented via kernel drivers. Without them the engine will not detect anything.

Thus the final answer is:

Yes, it is possible to install multiple anti-malware products on the same  system. Because this scenario is not supported by most security products, who would ask you to uninstall another product, this would require tweaks, such as deleting product installation information so the products would install together.
The detection rate in this scenario would only be limited to one of static/dynamic anti-malware engine, and runtime detection would not apply (it would have to be disabled).
As this configuration is unsupported and achievable only via tweaks, it is inherently unstable, and can collapse (crash/deadlock) easily. Especially once one of the security products receives a product update;
Running them in different virtual machines is a much better solution, as the resources used by the anti-malware product running scans would be quite significant;
Why not use VirusTotal instead?


Can a Trojan horse hide its activity from TCPView?

I don't think that a trojan horse will be specifically codded to hide
  from TCPview (or it is TCPview so popular that this happens?) but
  maybe there's a method to hide it's activity form any program trying
  to check the current internet connections (even wireshark) and what
  programs or windows processes (even svhost or system) are establishing
  those connections.

  If you know specific methods used to hide from TCPview could you
  mention them?

A kernel-level rootkit can hide itself from any user-level program on the system, which includes TCPview.  That's because all user-level programs make requests of the kernel in order to get information, such as access to network connection tables, interfaces, and packets.  The attacker "hooks" the kernel interfaces so as to intercept these requests, and so user-level programs may say "show me all the packets" and receive everything except the rootkit packets.

There's a good paper here called Countering Persistent Kernel Rootkits Through
Systematic Hook Discovery which describes the method by which rootkits do this pretty concisely.  To quote:

...a rootkit by nature is programmed to hide itself especially from various
security programs including those widely-used system utility programs such
as ps, ls, and netstat. As such for an infected OS kernel, the provided
kernel service (e.g., handling a particular system call) to any request
from these security software is likely manipulated. The manipulation
typically comes from the installation of kernel hooks at strategic
locations somewhere within the corresponding kernel-side execution path
of these security software.

  The reason I want to know this is I'm not sure that using TCPview or
  Wireshark to check for unusual connections is a bulletproof test to
  confirm that activity

If you think a system may be compromised, you can't trust a thing it tells you.  So external methods of checking, such as wireshark on a different machine (capturing via hub, span port, what-have-you) are necessary to get an objective view of network traffic.

The combination of external and information can also be very, very useful.  If you see lots of packets from remote:3456 to suspect:8080, but your suspect machine says it's not listening to 8080, that's a good sign you've got a kernel rootkit hiding its use of the network.


How to hide my website traffic from man in the middle?

Client browsing your web site will receive a certificate warning if the connection is going through a proxy unless the MITM server uses a CA that the client trusts as well for the connection so there is no real vulnerability as long as your users maintain their own security.

Alternatively, you can require TLS client certificate authentication on the server. You will then have to manage the secure distribution of the client certificate you accept but as long as this part of the setup holds, it won't be possible to perform a MITM attack on the connection.


Tor and regular browser side by side. Does that make sense?

Yes you can run them side by side and not corrupt the security. This is because your Tor browser will send everything through a Tor proxy (including DNS requests) and your normal browser won't. Do mind that:

If the NSA really would like to know what you are doing then they will find a way, bug your house, target your computer with malware, ... .


Need help understanding Windows Authentication mechanism

You initial request is likely to be a GET request, which if implemented as per standards will be a "safe method". That is, it doesn't make changes to any state.

Safe requests do not need to be protected because the Same Origin Policy prevents another origin (i.e. domain, protocol or port) from reading the response. Note that the request would still be made from the foreign domain, just that it has no way of reading the response in the request made through the user's browser.

Unsafe requests (which should be implemented as POSTs), should make use of a CSRF prevention method because even though the response can't be read in a cross-origin request, the requests is still made, and as it is "unsafe" it will have consequences (e.g. deleting an object that the user has permission to delete).

In this respect, "Windows Authentication" acts just the same as cookies in that it authenticates the user in their browser, but does not prevent cross-origin requests from making changes without some type of prevention mechanism (e.g. Synchronizer Token Pattern or X-Requested-With header to protect AJAX requests).


Is generating a unique token enough to authenticate?

Whether this solution is appropriate depends on a couple of factors.  As pointed out in comments the challenge with your outlined solution is that assuming an attacker can reach the service endpoint, they can complete the registration process and obtain valid tokens for use.

Will the service accept registration from any MAC address or just ones which you know belong to valid devices?  If the range accepted is limited it might be more difficult for an attacker to discover a valid address to make the request?
Will your service have any counter-measures against brute-force attacks?  Assuming the attacker can get the OUI for the MAC addresses you're using, they could cycle that space trying to get valid tokens.  In this scenario brute-force protections could help.
What security assertion are you looking to use this token for?  If you're just pairing a user with a device and then using it to stop the user logging in to multiple devices, then this could work to an extent, although there is a risk that the user could copy the token to another device and change the MAC address to match the original.


I think that you are over-thinking things! Also, you are not being realistic about the risks.

Also remember that any password is "security through obscurity" so it isn't always the "bad boy" it is made out to be.

So, a sensible approach might be a hybrid.

Low sensitivity logins - use a password manager. Most have various protections to help reduce the risk of malware hijacking data. Many also have 2-factor authentication capabilities which mitigate many issues. Examples: forums.
Medium sensitivity logins - use the password manager for convenience but add 2-factor authentication for security. Typically using your phone or some other hardware device such as a token. Soft tokens like Google Authenticator can be good as they are not totally dependent on one piece of hardware. Examples: social media.
High sensitivity logins - Store part of the password in your password manager and use a pattern to keep the rest in your head but still make it unique for each site! Also use 2-factor auth if available. Example: banking and finance

There are certainly many more ways to cut this. The main thing is to think about the risks sensibly and don't make life hell just to try and deal with a risk that is tiny or indeed an impact that would be tiny.


Is using WebAuthn alone considered as two factor authentication?

I think it depends if you are limiting access to your service by devices by some reasonable method.

If you have to use a domain joined laptop then probably yes. If you are using an app on a mobile device, then using the native biometrics capability to encrypt a secret then probably yes.


How does my browser detect my location, even via proxy?

Several proxies add extra headers to a session which leaks info such as the X-Forwarded-For header which includes the origin IP address.

Since OP question states there is no GPS/GSM network involved, then one can assume this is running on a desktop, laptop, or WiFi tablet, therefore the location data is likely being acquired by geoip data related to the IP address in the X-Forwarded-For header.

Testing headers

- login to a remote shell outside the proxy
- exec netcat -l -p 8080
- on local browse to remote:8080 with proxy enabled then read the stdout on remote

This also tests for additional data that may be sent. tcpdump can also be run on the remote server.


Found PHP script with erratic code, htaccess kept resetting even if I change it

It looks like malicious code was inserted in your index.php file.  I took a look at the code you posted at https://controlc.com/64190848, and this is obfuscated code.  I used unphp.net to de-obfuscate this code.  You can see the result at https://www.unphp.net/decode/200752e5c8246fc5472ddc5ab9a3734f/.  Clearly, this is malicious code.
As to how this happened - there are a number of possibilities.  Your hosting service may have been exploited.  Or, one of your PHP scripts (or a component or plug-in that you are using) may have a vulnerability which was exploited.
As to how to recover - hopefully you have copies of your PHP files from before they were exploited, and you can recover from these.  Going forward, you may want to host your own site, so that you have more control over your environment.  It's inexpensive and simple to setup a LAMP web server on a VPS using Amazon AWS, or another VPS provider.  You also might want to take a close look any components or plug-ins that you are using, to be sure that you have the latest versions of these, and that there are no reported vulnerabilities in any of these.  Last but not least, once you are back up and running, you might want to run a vulnerability scanner against your site, to see if it finds any vulnerabilities (this may have been what the attacker did, to exploit your site).


The website is simply asking the Google login handler to display the information to you -- and then placing it on the website in such a fashion that it appears to be the website knowing your logged in account. But in truth it's just a tag to them, like <%InsertLoggedInName%> or something like that.


Securely decommissioning a dedicated server

EDIT - OP feels original answer isn't up to SE standards. Left it below. Newer answer right here:

Two options for a full disk wipe. The first one takes advantage of disk drive controller secure erase capabilities, but not all drives have the capability and some BIOSes block the command. It's faster than the second option.

Have a look at hdparm: hdparm --security-erase <PWD> <device>
Check out wipe. You can fetch wipe with apt-get install wipe and wipe a disk with wipe /dev/sdb1.

Also, a lot of information here about clearing linux drives including sections on hdparm and wipe.

OLD Answer

Did you hit every part of the drive? What about swap files? What about /tmp directories? What about files that were already deleted? You really need to hit every byte deleted or not still on the drive not currently used by the OS. Then, what about bad sectors that the disk driver isolated automatically? You can no longer reach those, but a drive recovery service might be able to.

I wonder if you write a program that accesses the disk device drivers directly (/dev/disk0 on my machine) and overwrites it from there. It would be a relatively small bit of C code. The program would be read into RAM and run until the disk is wiped. However, the OS will no longer work after that, and definitely not after reboot. So, you only get to do this once.

The most paranoid agencies used to steamroll and now physically shred their disk drives. Sometimes people don't do what they promise they'll do.

How paranoid are you?


What can you do with a sufficiently complex quantum computer against Elliptic Curve Cryptography?

You can take a public key, and compute the corresponding private key. This private key is identical to the private key the owner has. All operations are possible and are indistinguishable, as the keys are the same.


How to extract intresting data from malicious e-mail header

I found something of your interest :

The sending IP address and the SPF validation will give you a very
good sense of whether an email truly comes from the person purported
to be sending it.
The line Received: from mout.gmx.com (mout.gmx.com. [74.208.4.200]) gives you the IP address from where the email is coming from.
Now, there are various websites that give threat intelligence reports such as VirusTotal. If you search about this IP address you will get an interesting report See this! The above address is reported by 2 firms also it's community score is quite shocking.


How does faked DNS manage to downgrade preloaded HSTS?

The domains google.com and www.google.com are not HSTS-preloaded. You can check that here. They don't even initially send a HSTS header.

Other subdomains of Google are preloaded, e.g. accounts.google.com.

Your assumption is correct that for a preloaded domain, accessing the site over plain HTTP in your browser should not be possible, regardless where you point the DNS. You simply checked the wrong domain.


However, once the license key is hashed (with salt) - it becomes very difficult to check if a given key exists in the database - since the salt used will change with each key.

Salts are designed to be used when you already have an identifier to look up the corresponding hashed field. For example, you don't look to see if "password" exists in any of the password fields, but rather that for "user" the password is "password".

If you're going to salt your passwords (licenses), then you need to assign a unique identifier to it which is stored without any hashing.

Prepend a unique ID of a fixed width to the first bytes of your licenses or use a delimiter and split the ID off before hashing on the server.


Can certificate signing requests be stored at the server to prolong existing certificates?

A CSR contains essentially the same information which end up in the final certificate, although the CA will likely add some additional information and might decide to ignore some information from the CSR. Specifically the CSR does not contain the private key for the certificate. Given that it should be no problem if the CA stores the CSR.


How safe is to store a AES encoded password into a file?

First, do you really need to use passwords? SSH keys would be much more suitable for "an automaton in the crontab to connect into others servers".

If you do need to store such passwords, the proper setup would be creating a specific (non-root) user account for this case, storing the file in a 400 permission file owned by this user, and having the automaton binary run with setuid bit (https://en.wikipedia.org/wiki/Setuid) set to the same account.

I.e., for a normal user account that file would be readable only through that automaton and not by any other means.

I don't think that encryption adds any security there if the storage of encryption key isn't any more secure than storage of the password.

If the automaton is a binary and you include a key there, then you need to ensure that it's executable but not readable. If the automaton is an executable script, then you can't store the key inside it securely at all.


Why touching a message with this text freezes the phone?

How the message works

This video explains it best:

https://www.youtube.com/watch?v=jC4NNUYIIdM

Brief explanation

There are a lot of special characters in the message. They can be displayed without any problem, but when the phone tries to work out how to show the selection popup the calculation crashes, causing WhatsApp to crash.

At a guess, the 0 width characters create a massive amount of options for what you could be selecting, leading to a massive amount of checks, which take too long, crashing the app.


Can not setting password for root when installing linux be exploited?

If you are worried about something or someone abusing this lapse and ending up logging in as root, don't worry: if root has no password set, no password will match and plain common login with that account (tty login, SSH login, X login, et al) will not be allowed.

But the account is still accessible: you can sudo su and become root. After that you can add a public key to /root/.ssh/authorized_keys and SSH-in as root.

But none of those methods will work when you don't have sudo powers, and you are probably the only one with that power on your system.


Hacked Ubuntu server, probably hacked commands (netstat, ps, ...), how to replace them?

You should "nuke it from orbit": wipe and reinstall the OS and applications from clean source media, and then carefully restore the data from backup.


They have video series on developing exploits with metasploit here
http://www.securitytube.net/groups?operation=viewall&groupId=0

Here are some other links
http://www.offensive-security.com/metasploit-unleashed/Useful_API_Calls

http://www.offensive-security.com/metasploit-unleashed/Exploit_Development

http://dev.metasploit.com/redmine/projects/framework/wiki/ExploitModuleDev

http://www.nullthreat.net/2011/01/fuzzing-and-exploit-development-with.html

http://www.securitytube.net/video/2321

http://dev.metasploit.com/redmine/projects/framework/repository/entry/HACKING

Also i recommend looking at exploits similar to what you want to do to see how they work.


OAuth2 JWT Signing with OAuth2 Application Secret Key

This sounds like a case where the new introspection service added to OAuth2 (https://tools.ietf.org/html/rfc7662) would be useful.  It allows your RB to validate the access token (the JWT) forwarded by RA against the AS.

This breaks your request that there is no communication between RB and the AS.  But that should not be a problem, as these services already trust each other.  There are no globally  known symmetric keys or implicit trusts between RA and RB involved.

Interpolating it into your stream:

RA requests an JWT from AS
AS responds to RA with a JWT
RA requests a resource from RB using the JWT
RB validates the JWT against the AS/introspection service
RB responds to RA with the resource data


Hashcat custom mask - brute force 12 length passwords with 1 capital letter, 1 number and 10 lowercase letters

You can't do that with a single hashcat mask, but you can make multiple masks. You need to use a multiset permutation for this. There are 132 possibilities, so need to generate a .hcmask file with 132 lines like this (in Python with sympy):

from sympy.utilities.iterables import multiset_permutations
import os

contents = os.linesep.join(list(map(lambda b: "".join(b), list(multiset_permutations(['?d', '?u', '?l', '?l', '?l', '?l', '?l', '?l', '?l', '?l', '?l', '?l'])))))

file = open("scan.hcmask", "w")
file.write(contents)
file.close()

Then use the .hcmask file in hashcat

This would require 26¹¹ · 10 · 132 ≈ 2⁶² hash computations, which would require about one to two years to crack assuming 70 GH/s.


Hijacking Websocket - it is possible to change the server response?

No, it's not possible to change the servers WS channel response (if you use WSS).

WSS is websocket with TLS security, its a thing. As with all things transport security related, the answer is TLS.

It's not possible to change the response when you use WSS.

If you design your system to use plain old WS, you must expect that it is possible.

Being TCP based, injection into a TCP stream has the same challenges all TCP connections have (which is hard to find, maybe a separate question?). It's much simpler with a machine in the middle attack.

The regular WS protocol wasn't designed to be secure. That's probably because they knew people would use TLS if they wanted security.

In the RFC, there is a description of an obscure kind of attack, that a proxy unaware of WS might fall for - see https://tools.ietf.org/html/rfc6455#section-10.3.


Let's begin with the easy part: Option #2 is a non-options. It comes with no CSRF-protection, so it is inherently vulnerable. Actually, option #3 is pretty much option #2 with CSRF-protection on top. So you are right to focus your question on the choice between #1 and #3.

  Are there any other benefits of Option 3 over Option 1?

Not really. And the I'm not sure the benefit you mention - being able to protect the JWT with the Http-Only flag - is that big of a benefit.

Being able to steal the JWT is convenient for the attacker, since she can then do whatever she wants to do from her own computer. But given a XSS vulnerability, anything she could do on her own computer with the JWT she can also do from the victims computer using injected scripts. That might be a bit more annoying for the attacker, but it would not stop a determined adversary.

So in the end, I think the choice between #1 and #3 mostly is one of personal preference. I personally like #1 better, because I find it cleaner and more straight forward. Plus it takes care of the CSRF situation in a neat way, without me having to lift a finger.

  If I go with Option 3, am I introducing some other attack vectors, that I havent't considered yet?

Maybe.

Generally, one weakness with the double submit cookie pattern is that it allows for subdomain attacks. This is somewhat mitigated by the use of a JWT. Since it is signed, a sibling domain could not rewrite that cookie. But (at least in some browsers) a sub domain could read it and hence perform a CSRF attack. Using a HTTP header rather than a form field for the double submit would make this attack much harder, if not impossible (barring something like a Flash exploit).

Note that the security of this option completely relies on you getting the CSRF proteciton right.

  Is there any other way of CSRF mitigation, instead of keeping state in front-end (localStorage/sessionStorage/Redux store/JS-readable cookie) which is always vulnerable to XSS?

No. If you're vulnerable to XSS, all CSRF protections goes out the window. And it doesn't really matter. Because if I can do XSS, I have no need for CSRF anymore. So trying to come up with a way to protect from CSRF in case of XSS is not only impossible, it's also pointless.

Every minute you spend thinking about how to protect your CSRF token in case of a XSS attack is a minute you should have spent trying to stop XSS attacks instead.


Is it possible to force client use TCP instead UDP for DNS queries?

You should read A Question of DNS Protocols by Geoff Huston, which is an actual investigation into this idea, with statistics and everything:

  If the DNS represents such a significant vulnerability for the
  Internet through these UDP-based reflection attacks, then does TCP
  represent a potential mitigation? Could we realistically contemplate
  moving away from the ubiquitous use of ENDS0 to support large DNS
  responses in UDP, and instead use DNS name servers that limit the
  maximal size of their UDP responses, and turn to TCP for larger
  responses?

I think the key points from that paper which address your question are:

If your server responds with partial UDP responses with the 'truncated' bit set, that will force clients to try TCP instead
Not all clients will be able to do so; 2% of clients and 17% of resolvers don't switch up to TCP (...as of 2013)

Personally, I think you'd be violating the spirit of RFC 1123:

  DNS resolvers and recursive servers MUST support UDP, and SHOULD
  support TCP, for sending (non-zone-transfer) queries.

I'm not sure faking UDP just to switch people up to TCP counts as supporting UDP.  That being said, there's always a gap between RFC and reality...


How to identify the right hash from a list of salts and pre-given password during authentication?

Someone is trying to log in. That means they've provided two things:

Who they claim to be.
Something they claim proves they are that person.

The salt should be tied to #1, as it's unique per user (and globally, but especially unique within your own database). Then you can just look up the user's information in your database, and the salt will be part of the information you retrieve.

The pepper is a single value added to all of the passwords to be hashed, but IMO it should not be hardcoded. Constant, yes, but if you keep it as an environment variable in the server or loaded at runtime from a file, then an attacker has to compromise your production webserver, not just the source code.

However, in general, the fact that you're worrying about salts as part of your webapp implies you're doing something wrong. You seem to largely understand how salts work, but unless this is an exercise whose whole point is implementing your own password hashing, you should really just use a standard solution. bcrypt has been the standard for years, and Argon2 is increasingly popular as well.


Should I block visitors who seem to be probing my site?

As a rule, the returns on this type of defense are nearly zero. There are exceptions, but even then this technique may offer only a small amount of security.

Exhaustive vulnerability scans of randomly-chosen hosts offer extremely low returns on scanning resources. Instead, successful attackers generally choose one of the following two options to increase their odds:

Check for a very small number of vulnerabilities over a large number of hosts
This includes bad passwords for common services such as SSH, POP3, cPanel, Wordpress, Joomla, and the like. If your root password is "root" or your site admin password is "admin", you can expect to get caught in one of these drift nets surprisingly quickly.
Starting with a single known vulnerability, use a search technique to narrow down your target list to only the most likely victims.
Usually this starts on one of the common vulnerability databases. He finds a recent candidate and identifies some string that would be common on vulnerable hosts. This is often a "Powered by" line or a login link or a specific URL pattern. Then, using his favorite search engine he retrieves a list of sites that follow that pattern.

The important point is that in neither of these cases does the attacker make more than a few attempts at a given site. Either they're successful immediately, or they move on.

That's not to say that you won't see the occasional persistent attacker. There's always some misguidedly optimistic individual running Nessus against a /16, but such attacks are by their very nature self-limiting and very rarely successful, since the vast majority of the attacks target software that a given server doesn't even run.

Could such an attack be successful? Yes. Does it ever happen? I deal on the average with several compromised servers per day, and so far I have yet to see even one come from nessus-style full-spectrum scans. But the probability isn't exactly zero. And in the world of random attacks, statistics and probability matter quite a great deal.

The exception is when the attack is not random. If you run a high-value or high-visibility site, you'll attract a lot of direct attacks against you in particular. Sites like Facebook, Twitter, Hotmail, etc., see an extraordinary amount of attack traffic. If you deal in this type of site, you probably already take security very seriously and aren't looking for advice.

A note about SQL injection: This type of attack does take some refinement; after catching an SQL error message in a cursory scan, an attacker may send several dozen queries to a given server to get the bits centered right. So theoretically a clamp-down response may prevent such an attack... but probably not, since he'll probably just return using a different IP. Since he's already alerted on your server, he won't be deterred by a blacklist. Better advice is don't run crappy software. There's no excuse for using non-parameterized queries today.


Do we need CSRF protection for WS-Federation Passive Requestor Profile?

CSRF requires the client to have a token that is submitted passively, e.g. a cookie.  The attack, also known as "session riding," forges a request that takes advantage of passively-submitted tokens-- the forged request "rides" on a legitimate session that is already established.

In step 4, the browser doesn't have SAML token quite yet, so CSRF mitigation is not necessary.

Step 6 might require a CSRF mitigation, but only if it has some effect, e.g. changing a password, transferring money, etc.  If its only purpose is to retrieve a web page for display purposes, CSRF mitigation is not needed.  (The goal of a CSRF attack is to issue a command, not eavesdropping.)

Presumably there may be steps 8, 9, 10, etc. where the user can actually have an effect on something.  Those sorts of transactions would require CSRF mitigation.

On a side note, step 0 does require a mitigation against session fixation.


Someone is bothering me by messaging through websites message services

Unfortunately there is no way to tell who it was sent from, at least without police involvement (such as a warrant to the SMS website). Even if you got this far, the most that the website would give the police is an IP address, and it would be even more difficult for them to tie this to a specific person. So realistically, unless these messages are threatening someone, there is no way to tell who these SMS messages were sent from.

As for blocking these SMS messages, you will likely need to approach it in 2 ways. If you get messages repeatedly from the same number, you can block messages from that number with either your phone or service provider. If the phone number changes each time but you know what service they're coming from, sometimes the service allows you to enter your phone number into a "do not contact" list. Otherwise, there's not much you can do to block these messages. You could change phone numbers or maybe set your phone to block text messages from numbers that are not in your contact list.


In virtual machines, the host is God. It can do anything. Even if you could keep all data encrypted (which would be expensive -- e.g. see this question), it still must be decrypted at some point within the CPU, so that processing can take place. The host has complete control of the CPU.

Encrypted RAM may be useful only in contexts where the CPU is assumed to be honest, and you try to defeat external peeking into the RAM (e.g. cold boot attacks). If your CPU is itself hostile to you, then there is little you can still do "securely" (although some people tried).


Would you typically want to monitor all ports for NIDS monitoring? If so, is span port or network tap the way to go?

Port mirroring, while possible even on cheap switches such as the Unmanaged Plus NETGEAR ProSAFE GS105Ev2 or the even better Easy Smart TP-LINK TL-SG108E, is a gamble due to timing and loss. It is very possible to configure a scenario where a long-term-running port mirror can continue to copy frames for months at a time without losing frames. You probably want to use an undersubscribed network with high-end Juniper Networks or Cisco gear, though, with good clocks and/or NTP configuration.

For taps, you can avoid oversubscription and switch max-CPU problems. If the switched network becomes problematic such as a spanning-tree event, you can still capture all of the relevant frames. Port mirroring can also cause a lot of packet de-duplication which may raise the CPU of switches to unwanted levels.

There are many tap vendors with a variety of different layouts and configurations. I suggest that you read this article -- http://packetpushers.net/practical-visibility-fabric-part-1/ -- which mentions the four major players in that space as well as gives plenty of background on how to go about building a visibility fabric, i.e., a place where you can configure a set of monitors such as network intrusion detectors.

An additional suggestion is to monitor and test the performance of your capture infrastructure with a tool such as -- https://github.com/adulau/netbeacon


Security risk with dynamically linked library

This is definitely dangerous as any program with the permission to change external storage (a large proportion of Android apps have this) can change the .so and run arbitrary code with your app's permissions.

If you really want the users to be able to change the library. You should provide a UI which allows them to pick a file and then copy the .so to your own app's /data directory before linking to it.


Server Compromised. Steps to determine further damage on the network?

"What steps do you take to feel confident..." Restore from back up. Now you said running as root so I will assume this is a Unix variant (Linux/BSD/etc) here are some things you can do to give you a baseline of what may be going on. 1) Take the machine offline if possible:

mkdir /tmp/DFIR
netstat -a | grep -i "tcp\|udp\|icmp" >> /tmp/DFIR/connections.txt
last >> /tmp/DFIR/lastlogins.txt
lsof ID_OF_SUSPICIOUS_PROCESS >> /tmp/DFIR/suspicious-PID.txt

Now that you have an idea of baseline things to look at, this will likely be a waste of time. Depending on what was used to get in, whether or not there is a backdoor, logfiles were erased, it can be a time consuming task. But if you want to continue...

Once you have the PID of the suspicious process, you can determine (if timestomp or chage wasn't used) when it came to light/modifications via the MACE times. You can take a stab at trying Volatility but unless you are already familiar with the gist of forensics, memory analysis is time consuming.

Now I will stop since the initial question was broad, you stated root, and for all I know, you're using Windows. My advice, restore from a backup unless there is something where you intend on pursuing civil or criminal charges. In which case, you would need an expert.

ADDED (EDIT)

Before you nuke the system, I would create a YARA signature to look for whatever you saw. I would definitely do the netstat to monitor connections, on the next install of ANYTHING, I would create a hardened remote syslog server, minimize access to the principle of least privilege, for starters. But again, as mentioned the question is really broad from the onset.


How useful is PDF signing in real world usage?

If Alice signs the PDF before sending to Bob, it will look like this:

source

If Eve changes anything on the PDF, when Bob opens it, it will show something like this:

source

The signature contains the certificate of the issuer, and if anyone but Alice signs the document in her place, the signature will not be valid, and the PDF reader will show the invalid signature message. What Eve could do is to remove the signature and change the PDF, akin to SSL-Strip on a PDF.

How Alice could make sure the signature isn't stripped? She could call Bob and say from now on, every single document will be signed, without exception. And put that message on her website. And on every email she sends. When Alice earns the reputation of sending only secure and signed emails and documents, few people will accept an unsigned counterfeit document.


not allowing pasting of bank account number

The problem isn't with pasting, it's with copying confidential data. The copy buffer isn't a protected resource and can be accessed fairly freely.

That said, account and routing numbers aren't really confidential as you give them out on every check so this idea sounds hair brained. Perhaps they do this to give the impression of security to less informed users? Perhaps they're just really confused.


Certificate chain and permission to revoke

Short answer: NO, Z can't revoke X directly.
Exception: YES, if Z's CRLs are, due to prior arrangement between Z & Y, in the CRL Distribution Point list of X's certificate that was issued by Y.

RFC5280 refers to this as "Indirect CRL" - where Z can issue a CRL that includes certificates issued by Y. It only works if the verifier knows where to check. The "CRL Distributions Points extension" of certificates is the place they (ought to) look.

It is well known however, that most certification verification algorithms are not strictly quality checked against the standards - and hence this system is fallible to a non-negligible extent.


This could very well be a malicious file. I would perform the following basic investigative steps:

stat the file # stat filename
use the modified and changed times from the stat and compare those to the web server access_log to track back how the file got there. Likely there will be a POST to a different script where it was uploaded.
If nothing is found in the access logs please check your FTP logs as you could have a compromised FTP user.

Cleanup:

Find and patch vulnerable file if confirmed through access logs
Change comped passwords and run anti-spyware on your local box
Remove malicious file


Ransomware - Full disk wipe versus formatting

Your disk wipe can be a useless/waste of time if no-one tries to recover those previously deleted files from that drive. In which case, a normal deletion of all partitions and formatting is all that's needed

or

It can be a good safety measure if you know that at a point someone will try to use recovery tools to recover deleted files from the drive.

This is actually about if you want to prevent infected files from being recovered or not.


If I include a Forgot Password service, then what's the point of using a password?

That's reasonable. From a security perspective, it is reasonable.  I know some people who never write down their passwords for web servers; they just use the "forgot my password" link every time they want to log in.

From a usability perspective, it might be a bit unfortunate, because email isn't instantaneous.  Users will have to click "Email me", then wait for the email to show up, then click on the link in their email.  Unfortunately, if users have to wait a few minutes (or even just 15 seconds) for the email to show up, they might get annoyed, give up, and go do something else -- or go to your competitor.

A further improvement.   It is possible to improve the idea a little bit further, to reduce the usability impact.  When the user clicks the link in the email, you could set a persistent secure cookie on their browser.  The result is that when the user clicks the link, they're in, and they won't need to go through the rigamarole again in the future on this computer (unless they clear their passwords).  On future visits from the same computer, the site will automatically recognize them and no login or links will need to be clicked.

This is not appropriate/sufficient for high-security services, like online banking, where you need to prevent the user's roommate from logging into their account -- but it might be fine for most web sites.

Evaluation. Here is a research paper that investigates this approach and finds it provides increased security against the attacks evaluated in the paper:

Chris Karlof, J.D. Tygar, and David Wagner.  Conditioned-safe Ceremonies and a User Study of an Application to Web Authentication.  NDSS 2009.


it worked after clearing the MAC OS CRL/OCSP cache which is located in
/private/var/db/crls/.


What are the dangers of client side authorization?

The server controls the important resources.  If the server cannot enforce access control then you have built a system without access control.


Securing the hardware of my computer against remote exploits

There have been vulnerabilities caused in how the operating system uses hardware.  For instance there have been vulnerabilities in systems using Intel processors,  although this vulnerability was fixed in the operating system,  just about every OS had to be fixed.

Drivers are usually the culprit.  Recently there was a privilege escalation vulnerability with nvidia's Linux driver.

There have also been vulnerabilities in wireless devices.  The most famous being the OSX Remote Code Execution vulnerability using malformed 802.11 frames.

Vulnerabilities in drivers are absolutely no different any other vulnerability (other than the fact that they are very uncommon and the payload usually runs in kernel-land).  To defend your self,  make sure your system is updated regularly.  Disable hardware that you are not using, (Like NFC on your phone!)


What actions are needed on the server when a intermediate certificate expires?

Validation of the end certificate would fail. However, intermediate certificates are typically valid for a much longer period of time than regular certificate, often 10 years. This enables the maintainers of the intermediate certificates to introduce a new intermediate certificate way before the old one expires, but after all end certificates expire, so in practice this situation shouldn't occur.


Are there any web application security standards?

From what I understand there is no 'universal' standard, however several standards do exist that you can use as a point of reference.

The National Institute of Standards and Technology [NIST] offers Publication 800-53
If you are dealing with healthcare
information there is the HIPAA set of standards
If you keep
credit card information there is the PCI set of standards
Finally there is a more generic OWASP Application Security
Verification Standard

These are just a few I know about. The standards you build for yourself will be dictated by the nature of your application and the information is serves/stores. However the above resources should help you get an idea of what things you might want to keep in mind or work into your own standard.


Why CORS is still securing an open api where all requests have a wildcard (*)?

In case of an open API, the only possible value for Access-Control-Allow-Origin is a wildcard (*), since you can't have a list of allowed domains.

Having a static * is one way. Other ways are to dynamically return the currently requesting origin inside the Access-Control-Allow-Origin header. These options slightly differ in semantics, specifically regarding handling credentials like cookies.

  Still, this seems not to bug developpers and appears to keep the system secure.

Since there are no actual security requirements for the API (i.e. everybody should be able to use it, even cross-origin) CORS does not keep the system secure. What the wildcard Access-Control-Allow-Origin instead does is to make the system working cross-origin in the first place: without any CORS header in the HTTP response any XHR interaction (i.e. write request and read response) could only be done to the same origin because of the default SOP for XHR.

  ... but as I understood it, it avoid an unwanted domain to use session cookies of a user without his consent.

CORS does not forbid things that are possible without CORS. It is still possible to send simple requests cross-origin with credentials (cookies ...) included, both with XHR and by including images cross-origin, sending forms cross-origin etc.

But CORS makes it possible to not only send simple requests but also non-simple requests (with additional headers, different content-types etc) and to read the responses for simple and non-simple requests. And when credentials are used not only Access-Control-Allow-Origin is relevant but also Access-Control-Allow-Origin: if this is not explicitly set to true the response will not be available to the script in the browser, similar to how it was done without CORS.


Is it critical to enable DNSSEC if I am using TLS/SSL certificate on a website?

Check out Cloudflare: How DNSSEC works - they do a great write up on this and why its important. If you are concerned about providing a secure experience to your end users, or use your domain to provide email services that you send or receive from. DNSSEC would be a good (and easy to setup) choice for you.