What client software is affected by JPEG 2000 / TALOS-2016-0193/CVE-2016-8332

The full CISOC TALOS report describes the vulnerability in incredible detail.  @dandavis comment already answered most of your questions but allow me to repeat that:

  Is the vulnerability specific to software that leverages this library?

Yes, only libopenjp2.so.2.1.1 is vulnerable (and likely older versions of it).  Other JPEG2000 libraries are not vulnerable.

  Does the vulnerability occur when creating or viewing this image format?

It happens when viewing a cleverly crafted image.  The library wrongly parses the MCC (motion compensation), i.e. not safely enough.  You can craft an MC that will result into an arbitrary pointer, and then the next MC writes something to that pointer.  In general you can write at arbitrary heap positions.

  Are all viewers vulnerable?

Actually a rather limited number of viewers is vulnerable because JPEG2000 did never really catch.  According to the report the notable vulnerable viewers are Poppler, MuPDF and Pdfium.  Poppler being the most notable since it is used as a library in several PDF rendering applications.

  How can I identify if my viewer is vulnerable? (Adobe, Chrome-built in reader, etc)

Let's go through a couple of ways of identifying vulnerable binaries.

Poopler is the most notable software package, and its pdfinfo, pdftocairo, pdfimages (and others) are clearly vulnerable.  On Linux:

[root@haps ~]# ldd /usr/bin/pdfimages | grep libopenjp2
    libopenjp2.so.7 => /usr/lib/libopenjp2.so.7 (0x00007f0be0bfa000)
[root@haps ~]# ls -l /usr/lib/libopenjp2.so.7
lrwxrwxrwx 1 root root 19 Aug  4 21:08 /usr/lib/libopenjp2.so.7 -> libopenjp2.so.2.1.1

Yep, definitely using the vulnerable openjp2 2.1.1 .

Thankfully, most software* today use the cairo libraries instead of poppler  for example:

[root@haps ~]# ldd /usr/bin/gimp | grep pop
[root@haps ~]# ldd /usr/bin/gimp | grep cairo
    libpangocairo-1.0.so.0 => /usr/lib/libpangocairo-1.0.so.0 (0x00007f4ce1d9f000)
    libcairo.so.2 => /usr/lib/libcairo.so.2 (0x00007f4ce110f000)

The methods above use ldd to check dependency on libopenjp2.  But that is not a bullet proof method.  Software loads shared libraries at runtime, for example the browser I'm posting this from will not use libopenjp2 for JPEG2000 images:

[root@haps ~]# lsof /usr/lib/libopenjp2.so.2.1.1
[root@haps ~]# lsof /usr/lib/libjpeg.so.8.1.2
COMMAND PID     USER  FD   TYPE DEVICE SIZE/OFF    NODE NAME
firefox 522 grochmal mem    REG    8,3   432880 3844022 /usr/lib/libjpeg.so.8.1.2

But will use libjpeg for all JPEG renders.  Even for JPEG2000 (JPEG2000 atoms are optional).

Extra note

libopenjp2 2.1.2 which fixes the vulnerability is already available.  The public disclosure of the vulnerability happened a day after this version was released, i.e. it was a responsible disclosure.  (I have just updated it on my machine a couple of hours ago.)

* The example uses GIMP, which isn't a particularly good example since it uses plugins that may load extra libraries (thanks @MichaelSchumaher for reminding me of that.).  On the other hand the JPEG2000 plugin for GIMP did not really catch either, just like the JPEG2000 spec itself.  The plugin had a usage fewer around 2008-2010 but went into disuse since then.

GIMP has also file-pdf-load which use poppler.  And moreover, anyone can write GIMP plugins that may include libopenjp2, therefore you may load the library into memory and use it to open a JPEG2000.  This isn't exclusive to GIMP but any application that allows plugins that load extra shared libraries.

In summary: if you are explicitly loading a plugin to use the libopenjp2 into your application, then you are vulnerable to CVE-2016-8332 (unless you use the updated library, that is)


Privacy alternatives to keep sensible data secure?

Using a reputable VPN will solve some of your problems. If you are paranoid about 3rd party VPN providers snooping your traffic you could create your own. Here is a good guide https://www.linode.com/docs/networking/vpn/set-up-a-hardened-openvpn-server.

It check out this list for info on 3rd party providers https://thatoneprivacysite.net/vpn-comparison-chart/.

Note that I am very paranoid and have no issue using my chosen 3rd party provider.


What information is being transmitted to the carrier when making a call on a GSM network?

In general for GSM, SIM card information is used to authenticate the user. Your identifier is the IMSI (international mobile subscriber identity) which identifies you uniquely. It's present on your SIM and is what you can consider your login credentials. The IMEI on the other hand just identifies your mobile phone. You can consider your IMEI like a MAC address of a network card.

There are three algorithms that are used, A3 (authentication), A5 (encryption), A8 (session key generation). Your SIM card will receive a challenge from the celltower to authenticate itself and your SIM card will generate a signed response to proof you are indeed who you are claiming to be.

If you are roaming the challenge and validation of the challenge will actually be done by your own carrier as the A3 and A8 algorithms can be chosen, they are not standardized algorithms. Your carrier will then inform the partner on which you are roaming if you signed the challenge correctly or not.


You can also add session.entropy_length = 512 and session.use_trans_sid = 0.

Also do not forget to:

use https
regenerate session id if you change users permissions.
do sessions time out. Time depends on your app.

It has nothing to do with security, but why not to change session.hash_bits_per_character to 6. The bigger the number, the shorter the string sent from and to the server.


what is the link between server certificate and cipher list advertised by server for nmap command?

... server also advertises

The server does not advertise any ciphers. The client advertises ciphers and the server either can choose one of the advertised or not. Detection of server supported ciphers like done in nmap just tries varies ciphers and see if it succeeds.

  Here key-exchange used = ECDHE. Authentication = ECDSA.
  It means server using ECDHE certificate?

There is no such thing as an ECDHE certificate. ECDHE is a key exchange which is not a property of the certificate. The relevant part here was "Authentication = ECDSA." instead, i.e. an ECC certificate where ECDSA is used as signature algorithm within authentication.

  Key Exchange used = RSA. Authentication = RSA.
  How come TLS_RSA_WITH_3DES_EDE_CBC_SHA agreed for ECDHE certificate?

A server can have both an ECC and RSA certificate, i.e. two different certificates for the same site on the same server. If the client supports ECDSA then the server will pick an ECDSA cipher since ECC certificates are smaller for the same security than RSA certificates. If the client only offers RSA ciphers it will get the RSA certificate.


Should every SAML identity provider provide a unique public certificate to the service provider?

It is not specified that the certificates for two idps must be unique. As far as I know you dont even have to have a certificate. But its recommended.


Is it better to use a root password, or use 'sudo bash'?

For a single-user system, there's not much difference between the two from a security perspective: in either case, the attacker needs to guess one password to gain superuser privileges.

The big difference shows up in a situation where you've got multiple administrators.  In that case, requiring sudo creates an audit trail of exactly who performed which administrative action.


How can I secure Wifi against these specific attacks?

An unauthorized party gaining access to the network without any prior knowledge (eg. by a neighbor brute-forcing the PSK)

If you have a sufficiently strong password, such as }H/,uj^kGbtQ(WtqjdY{KCdQT[_G@[R>Bm+~\Sb[X(3na, then the chances of an attacker recovering this password with brute force are negligibly small. Note that this doesn't prevent an attacker from gaining access to the password in other ways, such as social engineering, but it protects you from an attacker capturing a handshake and cracking it offline.

  A user that is authorized to use the network as a user (eg. no access to the router's admin panel or the RADIUS server) decrypting another user's data to violate their privacy.

WPA2-Enterprise with endpoint certificates will solve this.

  A 3rd party attacker (or an authorized user) that sets up an evil twin attack and is able to get the PSK (or RADIUS credentials) and/or the data itself, thus violating all users' privacy and/or accessing the network without authorization.

This answer by Matthew Peters excellently describes how an Evil Twin attack can be mitigated. It also includes using WPA2-Enterprise.

  But what if my client device does not support WPA2-Enterprise?

Many consumer devices, and even some business devices, are not built to support WPA2-Enterprise, such as some phones, printers, handheld game consoles, various "smart" devices, etc.

In this case, your only option lies in using WPA2-PSK, with all its associated risks. Again, using a long, randomly-generated Pre-Shared Key is the best option you have.


Usablity vs security malicious file upload

If you disallow file uploads, researchers will host their proof-of-concepts elsewhere and provide you with a link to the remote resource, leaving you with essentially the same problem.

The common practice varies. The popular platform HackerOne (which provides pretty much the service you described) allows file uploads, but includes an appropriate warning before offering the download. Google's bug bounty program, on the other hand, does not allow uploads on their bug report form.

Either way, your response team should work in a sandboxed environment and open files only if necessary. I disagree that uploads are "a core feature", as many vulnerabilities can be explained without attachments but via plain text and inline code snippets - although your customers might think otherwise.

Hosting the attachments securely is a topic to itself, but most importantly, you should store all user uploads on a server separate from your web application.


Mozilla: https://mozilla.github.io/server-side-tls/ssl-config-generator/
SSL Labs: https://github.com/ssllabs/research/wiki/SSL-and-TLS-Deployment-Best-Practices
Cipherli.St: https://cipherli.st/
OWASP: https://www.owasp.org/index.php/SSL_Best_Practices

And here: especially the "Related articles" section at the bottom: https://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet

Similar question: Now that it is 2015, what SSL/TLS cipher suites should be used in a high security HTTPS environment?


What is the meaning of http://uri.etsi.org/TrstSvc/eSigDir-1999-93-EC-TrustedList/SvcInfoExt/RootCA-QC from ETSI TS 102 231 V3.1.2

I just found the answer from COMMISSION DECISION 2009/767/EC

The meaning of http://uri.etsi.org/TrstSvc/eSigDir-1999-93-EC-TrustedList/SvcInfoExt/RootCA-QC additionalServiceInformation extension is stated directly in that document.

  As a general default principle, for a listed CSP in the Trusted List
  there must be one service entry per single X.509v3 certificate for a
  CA/QC type certification service, i.e. a Certification Authority
  (directly) issuing QCs. In some carefully envisaged circumstances and
  carefully managed conditions, a Member State Supervisory
  Body/Accreditation Body may decide to use the X.509v3 certificate of a
  Root or Upper level CA (i.e. a Certification Authority not directly
  issuing end-entity QCs but certifying a hierarchy of CAs down to CAs
  issuing QCs to end-entities) as the Sdi of a single entry in the list
  of services from a listed CSP. The consequences (advantages and
  disadvantages) of using such X.509v3 Root CA or Upper CA as Sdi values
  of TL services entries must be carefully considered and endorsed by
  Member States. Moreover, when using this authorized exception to the
  default principle, Member State must provide the necessary
  documentation to facilitate certification path building and
  verification.

So the meaning and purpose of that extension is to clearly indicate (As a warning?) that the way the X.509v3 certificate is being associated to the TSP service is not under the default principle of including the direct CA for end user accredited Qualified certificates.

This would mean that in the original example without including the http://uri.etsi.org/TrstSvc/eSigDir-1999-93-EC-TrustedList/SvcInfoExt/RootCA-QC additionalServiceInformation in the TSP, constructing a certification path including B and C certificates wouldn't be appropiately supported by that TSL.


Where can we learn more about recursive encryption schemes?

To me the idea doesn't sound like a good one. The security added by repeating the process (encrypt, shuffle, zip) over and over is marginal at best. You'd be better off increasing your key size (say from 128-bit to 256-bit).

Where can you learn more about such a construction? I've seen similar ideas proposed by companies trying to make "unbreakable" crypto, etc. Google "schneier doghouse" (without quotes) and you are bound to find a number of them in Bruce's doghouse.


Zone elevation protection in Google Chrome

The zone concept first appeared in Internet Explorer 4 (1997). It got prommoted to more prominent status in Internet Explorer 5. It was microsoft's attempt to model the web in discrete steps of trustworthyness/danger. Most other browsers use the white-list(trusted) and black-list(dangerous) method instead of zones.

What Internet explorer is doing is protecting it's zone concept by preventing a dangerous site from redirecting to a trusted site and doing some cross site scripting (XSS) when IE things it is at a trusted site. Really a IE specific XSS defense.

Google Chrome Preferences in the "Under the Hood" tab the "Content Settings..." allows you to set exceptions (white-lists) to the content restriction rules. This is a more fine grained level of control because you can set exceptions on a per site basis rather than for every site defined to be in a particular zone.


Is it safe to encrypt multiple files with the same strong passphrase?

As stated at http://tools.ietf.org/html/rfc4880#section-13.9 OpenPG (and thus gpg) uses a variety of the CFB mode. Especially by prepending a full block of random data to the plaintext key reuse does not reveal additional information about the plaintext to an attacker.
As far as I understood gpg deterministically computes the key from the entered passphrase. (See comment from dave_thompson_085) And gpg also uses the same IV (all zeros) every time. But because of the used cipher mode the answer to your question is: yes, it is safe to use the same passphrase for multiple files if you don‘t care about the typical password reuse issues (but that‘s not the scope of this question).


What happens when your secret API key is stolen and used by others?

As you may expect it, there is no way to fully protect your api key
if it is directly used by a client application. The user can sniff his
netowrk (the use of https or of an encrypted channel might still
help but is only a matter of time as the user can see the full
handshake) or reverse engeneering the software (same here, you can
encrypt the api key but with some work, you can always get the key
back).
Yes, you will still get charged even if the api key is not used accordingly to what you may expect simply because the api service has no way to know if it is some of your intented use.
There is only one solution which can fully secure your api key from being grabbed and used as not intended : do everything with the api key server side. Your server will act as proxy between the client application and the api service and thus, the client can't be aware of the api key. Howewer, it may cost you additional cost to set up a server.


How can I constrain or limit 3rd party Javascript (*.js) files that can DOS my site?

No.  In practice, there is no good solution to this problem.  If you include a third-party Javascript library into your web page (via <SCRIPT SRC=...>), you are trusting that Javascript.  That includes trusting it not to DoS you.  That's just how it works, and there's no solution, given the current browser security model.

If you don't trust the third-party Javascript, don't embed it into your web page.  That's the only reasonable solution today.

(In principle you could use Caja, but it's a pretty complex mechanism: this is a bit like using a cannon to shoot a fly.)


Full disk encryption vs targetted partition encryption for security experts?

It's not clear how you're defining "security experts". That term can mean different things to different people. It seems more like you're asking about advanced Linux users who know how to create granular encryption schemes.

As with anything involving security, it at least partly depends on what threat you're trying to protect against.

If you have a laptop that you carry around everywhere, and for which you are the sole operator, you might choose to keep most or all of it encrypted. Whereas, your workstation at your place of employment, or your kodi box at home, might not demand the same level of security. And if you are up against state-level actors, that's a completely different game to just wanting to be able to protect against casual theft.

You also need to consider the hardware. Solid state drives don't play particularly nicely with encryption.

On several of my machines I have a mix of rotational drives and SSDs. I put /var, /home and swap in LUKS partitions on the larger rotational drives and put / on an SSD. Given my threat model, this seems like a good compromise between getting the most utility out of the SSDs while still keeping most important data reasonably secure.

You mention directories like /tmp. Depending on your configuration/distribution, this will often be a tmpfs, i.e. it will be kept in memory. In that case, it will be both fast and also no need for encryption. If you're up against an actor that can perform cold boot attacks and extract the contents of a tmpfs, well, I guess you'll need to think about how to protect against that.

If you're up against a state level actor and you ever don't have complete provenance over the physical components of the device for their entire lifetime then all bets are off.


There are two approaches I would look into in order to accomplish this. The first is "Cornell Spider", it has the capabilities of looking inside of files for patterns. It's typically used to search for data such as social security numbers, PII, CC data. It is flexible enough that if the sheet you found has any patterns, you can hone in on those patterns and created a regular expression to search for.

An alternative way, is let's suppose that the file you found contains usernames and email addresses. Say: james.smith@mycompany.com You can use Powershell on a Windows machine to find files that contain those strings:

Get-ChildItem  -rec | ?{ findstr.exe
/mprc:. $_.FullName } | select-string
"@mycompany.com"

On a Unix based machines you could do the same thing but 1) it's really ugly, noisy, and long:

find / | xargs grep -i "@mycompany.com" >> /tmp/POSSIBLE-PII.txt

It all boils down to how that file has data structured. There are also commercially available tools that will do similar searches. Had I to tackle this, I would look for a commonality of what was in the file you found (usernames, amount of characters, domains, etc) and create a regular expression to look for files with those commonalities.

The issue with commercial tools, is they will likely be pre-populated with canned searches (SSN, CC, medical codes, etc). You are needing to find specifics. You could loop what you already discovered into another search. E.g., suppose the file you had was named passwordlist.txt you could iterate through every line, and have grep or powershell look for those instances in other files.


Which protocol could have been likely candidates for leaking a laptop serial number

It was probably likely that by 'serial numbers' they were referring to the MAC addresses of the devices, rather than the physical security numbers of the device.

  A prosecutor told the court: "A mobile phone and hard drive were also seized and the IP address... matched the intrusions into the organisation.

There is a protocol known as ARP, or the Address Resolution Protocol that converts IP addresses to MAC addresses, so that traffic knows which address to send given data to, and is commonly used as an identifier for where attacks originate from, what machines have egressed to a given network, where malware originated from within a company, etc. etc.

But to answer your question, there isn't any need for a physical security number to access a network for two reasons.

MAC addresses serve as individual identifiers
Numbers, like MAC, IP, and hypothetically serial numbers can all be spoofed.

If you need more info on any of these topics leave a comment and ill do my best to answer your questions.


what scanning tools are unlikely to set off network IDS?

As with most things - it isn't about the tool, it is how you use it.
Take nmap for example.
Beginners to the tool or script kiddies might run scan using the default option.

nmap 192.168.1.0/24

The default behavior for nmap without specifying any addition flags would be to perform a syn scan, so the above query would be equal to.

nmap -sS 192.168.1.0/24

Syn scans are reasonably stealthy. However, most modern firewalls/IDS should be able to detect syn packets as it is a very common scan technique.
Slightly better but still inexperienced users might perform even noiser scans using nmap.

nmap -sV 192.168.1.0/24
nmap -A 192.168.1.0/24

An nmap scan triggered with those two scan flags are VERY noisy. In addition to sending a variety of packet types and grabbing banner information, nmap will use the nmap scripting engine to perform additional tasks such as bruteforcing the SNMP community string if applicable. Such scans will be easily detected.
More experienced users can perform more stealthy scan types by specifying certain flags. nmap is a very powerful tool as it allows you to set different flags in a TCP packet to evade firewall rules. ACK & FIN are two very commonly used techniques to evade firewalls.
Other advanced techniques like idle scan can also be performed using nmap. It is a very versatile network scanner that can be very silent in the hands of an advanced user.
Some tips
Do not perform syn scans or version scans on entire subnets unless needed. It is slow and noisy. Instead, use the ping scan option to find out which hosts are active on a subnet.

nmap -sn 192.168.1.0/24

This option would return a list of active host IP and MAC addresses in the subnet.
Once you have obtained a list of active hosts, selectively scan hosts which you think are interesting. For example, the IP address 192.168.1.1 seems interesting to me, I might want to know more about it. Perform a syn scan.

nmap -sS 192.168.1.1

By default, nmap scans for the most popular thousand or so ports according to a list compiled by the author. This is good enough for most purposes. However, there might be some scenarios where you might want to specify specific ports. You can do that using the -p flag.

nmap -sS -p 80 192.168.1.0/24

This scan would send syn packets to the entire subnet, searching for active IP addresses with port 80 open. This is a useful scan for determining which host might have an active HTTP server.

nmap -sV 192.168.1.1

The -sV flag specifies the version scan option. This option instructs nmap to send a wide variety of packets to the hosts and scanning the headers of the packets returned to check for the exact version of a service the host is running.
This is a very powerful but noisy version. Use with caution.

nmap -A 192.168.1.1

The -A flag instructs nmap to use an aggressive scan. This is one step up from the version scan and utilizes the nmap scripting engine. This is very noisy.
nmap is a highly powerful tool. If you want to learn more, i highly suggest you pick up the book written by its author.


Why does AES encryption take more time than decryption?

Several symmetric block ciphers (specifically ones like AES, DES, Blowfish, RC5) will take the same amount of time (within measurement error) for encryption and decryption, when operating on a single block (e.g., 128-bits for AES).

However, there are a couple reasons why it appears different when encrypting/decrypting multiple blocks.  For example, with cipher-block chaining (CBC), encryption must be done sequentially (encrypt block 0 before you can encrypt block 1 before you can encrypt block 2 ...), while decryption can be parallelized as the XOR step (with the previous block of ciphertext) is done after the block cipher is applied.

See the diagrams below (XOR is denoted with a circled plus ⊕).  To encrypt the second block of plaintext p[1], you use c[1] = AES_Encrypt(p[1] XOR c[0]), this means you can't generate c[1] until you are finished generating c[0].

Meanwhile to decrypt the second block of ciphertext, you use p[1] = c[0] XOR AES_Decrypt(c[1]).  This is not dependent on the previous block of plaintext p[0] so can be completely parallelized (and can run much faster on multi-core systems).

If you want fast decryption and encryption, you may consider using CTR as it can be parallelized on both encryption and decryption.

You also potentially should be wary of tests that are skewed because of caches on your system.  If you randomly decide to read a file from disk and encrypt it, it will take several milliseconds to read each chunk of the file; however the next time you access it the file will generally be cached in memory and be accessed much quicker.  Meanwhile for your decryption test that encrypted file that was recently written to disk will likely still be in a cache in memory and will not suffer the penalty from reading from disk.

CTR Timing

$ time openssl aes-256-ctr -e -salt -pass pass:passwd -in Fedora_64-bit.vmdk -out vmdk.encrypted

real    0m58.217s
user    0m5.788s
sys     0m8.493s
$ time openssl aes-256-ctr -e -salt -pass pass:passwd -in Fedora_64-bit.vmdk -out vmdk.encrypted

real    0m34.780s
user    0m4.800s
sys     0m7.748s
$ time openssl aes-256-ctr -e -salt -pass pass:passwd -in Fedora_64-bit.vmdk -out vmdk.encrypted

real    0m34.989s
user    0m4.120s
sys     0m6.444s
$ time openssl aes-256-ctr -d -salt -pass pass:passwd -in vmdk.encrypted -out decrypted

real    0m35.944s
user    0m4.140s
sys     0m7.008s

The first three encryptions show the effect of the disk cache, where the first access of a file was much slower than subsequent accesses.  It also shows that for CTR that both encryption / decryption of this 7.4 G virtual machine took roughly 35 seconds.  (On repetition occasionally, decryption would be faster or slower).


Any way to get high quality live proxies other than buying them from a website?

The sites that sell proxies either have setup these proxies themselves or just scan the internet and look for open proxies. As you discovered yourself, these free proxies are usually not safe. They might sniff the traffic, inject advertisements or even malware - because this is their business model.

The only way to get a proxy you could consider as secure is to either create such a proxy yourself or to somebody you trust with creating such a proxy. This rules out any companies or tools which just find such proxies, because there is no way to find out if the proxy is really secure, i.e. not modifying the traffic and not even sniffing to the traffic, not keeping log files etc.


How do I protect a secret from rubber-hose cryptoanalysis?

The only way to protect against a human leak is making sure the potential leaker doesn't know the secret.

This usually come by redefining the condition of access. Unfortunately for you, there is no magic bullet here: what will work and what won't is typically dependent on what condition you want to setup.

Let me give you a few examples:

In the case of code escrow, a contract is passed with a third, trusted, party that will release the secret (the source code) in specific case.
In the case of bank vaults, it could be setup to only open during business hours.
In some spy stories, you might have someone mailing the decryption key to themselves (creating a period of time during which they have no access).

In the end, as often, it all depends on your threat model.


What's the danger of an online resume (a CV)?

You open yourself up to the possibility of receiving spear-phishing calls, texts, emails, and so on. This information could be used by an attacker to impersonate you as part of a social engineering attack against, for instance, a call center employee at your phone company in order to gain more information about you (date of account registration, address history, etc.)


Why should memcmp not be used to compare security critical data?

Exploiting timing information is one possible attack against things like password authentication systems.

Conceptually memcmp() works by comparing two sets of binary data on a byte-by-byte basis (in reality processors can compare multiple bytes at a time, depending on optimizations, but the same principles below will apply). The function starts at the beginning of the data, compares each byte sequentially, and exits as soon as it finds a difference. If no difference is found then the function returns a code indicating that the data matches.

Because the function returns as soon as it finds a difference, an attacker with a sufficiently accurate clock can deduce secret information. They can induce calls to memcmp() with different inputs and by measuring which inputs take longer they can deduce what a stored secret might be.

Example:

Consider a classical password hashing system. Suppose your password is stored as a secret hash, say for example Ek8fAMjPhBo. (That hash was generated using the DES scheme provided by the Linux crypt() function with a salt of na and a password of secret. Note that this function is insecure and you should not use it in real systems.)

In a strong password system your hash Ek8fAMjPhBo is stored, but your password is not stored. When you are asked to authenticate the system will take your password, hash it, and then compare the two hashes to one another. If the resultant hashes match then you are granted access to the system, if the hashes do not match then your password is rejected. This allows the system to check to see whether or not you know your password without actually storing the password itself.

How an attacker can use timing to attack this system:

In order to attack this system an adversary really just needs to figure out what password hashes to the stored hash. Normally the stored hash is kept secret, but the adversary can use timing information to deduce what the stored hash could be. Once the adversary deduces the stored hash it is vulnerable to much faster and off-line rainbow table attacks, as well as circumventing on-line security measures like password retry limits.

The password system above has to compare a candidate hash against the stored hash in order to function properly. Suppose it takes 10 nanoseconds to compare each byte of the candidate hash to the secret stored hash. If no bytes match (one comparison) then memcmp() will take about 10ns. If one byte matches (two comparisons) then memcmp() will take about 20ns. Your attacker generates a few passwords and runs them through the system, recording how long each one takes. Suppose the first few hash comparisons take about 10ns each and then return, indicating that none of the bytes of the candidate hash match the stored hash. After a few tries one of the hash comparisons takes 20ns- which indicates that the first byte of the candidate hash matches the stored hash. In the example above this indicates that the attacker has deduced that the first byte of the hash Ek8fAMjPhBo is E.

Hashes by design have the property that you can't predict what hash will correspond to what password, so for example this does not tell the attacker that the password starts with s. However, the attacker could have a large table of pre-computed hashes (a rainbow table) so they can look up other passwords that hash to a string starting with E. After they try enough hashes they'll eventually get an input that causes memcmp() to take 30ns, which indicates that the first two bytes match, and they have deduced that the first two bytes of the hash are Ek. They repeat this process over and over until they deduce all or most of the hash. At that point they either know the password or can brute force it with a traditional rainbow table attack.

This is a little hypothetical, but you can find lots of practical information about timing attacks elsewhere on the net, for example:

https://research.kudelskisecurity.com/2013/12/13/timing-attacks-part-1/


Which implementation of Salsa20 should I use?

If you're already using OpenSSL in your application, version 1.1.0 has the ChaCha20 cipher, which is a newer, improved Salsa20 variant designed by the same author (Daniel J. Bernstein).  So I would consider using that.

If you're not using OpenSSL already, you might want to consider NaCl or Sodium instead, which are much easier to use safely.  For example, they focus on providing high-level public-key AEADs (authenticated encryption with associated data) instead of just low-level crypto primitives like stream ciphers and MACs.  These libraries use Salsa20 internally.


What is the validity of the article which claimed that IE is more secure than Chrome?

Don't believe 100% everything you read.

Personaly, everytime I see one product outpreformed others by huge margin I assume this is a case of PR and not of pure cold facts.

There are lots of events when, let's call them, hackers and enthusiasts are trying to bypass browsers defence. Call me sceptical, but to me they have much bigger value then any article on any site.
E.g. Pwn2Own


If I browse a website over HTTPS using a VPN, can the data be sniffed somehow?

If you really used proper end-to-end HTTPS then nobody in between your client and the server could sniff it, no matter if VPN or not. Of course this means that there is a proper certificate validation and you did not skip warnings about invalid certificates.

Thus I would consider it more probably that the data were sniffed either before they got encrypted or after they got decrypted, i.e. outside the HTTPS tunnel. This could be attacks like this:

The server of the merchant was hacked and the card data leaked to the attacker. Or the data leak was at the card processor.
Or data leakage at your own computer, i.e. some browser extension or other kind of malware which grabs the credit card information before they get encrypted with HTTPS.
Or you got tricked into visiting the wrong site. If you are looking for the cheapest price it might be that you simply got tricked into visiting a good and trustable looking web site which was not so good and safe at the end. It might be that the shop simply could offer the cheap prices because it then used the card data in another way too.

Note that using HTTPS just make sure that nobody in between can read the data. It says nothing how trusted a site will be and how good the security at the side is. Everybody can get a certificate for it's site, even bad guys. And it does not help if your own system is insecure.


How does correct grammar affect password security?

In general, any information which can narrow the search space for a password will
reduce the strength of that password. So, in theory, it would make sense to assume
that grammatically correct passwords are potentially weaker than those which are a
collection of unrelated words or have deliberate grammatical errors. However,
calculating exactly what the differences would be is extremely hard.

Many password cracking programs will allow you to define complex patterns. For
example, it has been observed that people often use dates as a way of including
numbers in a password i.e. password1961 or even password171067 (or password101767 for
US date), so some password crackers will search for things like
[dictonary-word][year] and [dictionary-word][date], where the numbers in the
year/date will be restricted to digits which would be valid and within an 'expected'
range (i.e. assume year/date is related to current/recent period or users date of
birth etc). Likewise, studies of passwords indicate people tend to do things like put
'special' characters at the boarders of password components i.e. password:1972. This
might suggest it would be a good idea to not use digits of this format and consider
using 3, 5, 7 digit numbers rather than 4 or 6 and if you add special/punctuation
characters, do so in /unusual/ positions i.e. pas:sword1972 (and of course, don't use
'password' :-(

As a cracker, the challenge of using grammar would be in how to model it. For
example, English has a very complex grammar. This is partially why natural language
processing is such a challenge. Theoretically, if you could define the grammar with
sufficient accuracy and had a large enough dictionary, you could generate a system
which could produce a dictionary of /valid/ sentences. However, this would still
represent a very large search space. If you know exactly how many characters are in the password, this would help reduce the search space, but it would be very
large. What would need to be determined is how much smaller such a dictionary would
be compared to a similar dictionary just consisting of random words concatenated
together. It would be smaller, but whether it would be sufficiently smaller to make
any practical difference is unknown. If the grammar based dictionary meant an average
search time of 50 years and the random word dictionary represented an average search
time of 500 years, in reality, neither approach are going to be useful (assuming
there are no other optimization which could reduce the time to a level which would be
practical).

Rather than a grammar based dictionary, I would probably compile a dictionary based
on quotes, well-known poetry and song lyrics. My theory is that when people use a
phrase as a password, that phrase will be something which is easy to remember and
therefore likely based on a song, poem or favourite quote. This would be an even
smaller dictionary. The challenge would be in building the database and ensuring it
is sufficiently comprehensive. Probably something which is getting easier given all
the digital repositories of quotes, songs, poetry etc out there.

Personally, I wouldn't worry about this too much. Obviously, it would be best not to
use well know phrases and it would be quite important to not use a phrase which
someone might be able to identify via social engineering techniques. If your a
military person, don't use famous military quotes/speeches, if you're a Christian,
avoid using quotes from the Bible, if your an obsessive fan of some
singer/actor/whatever, avoid using quotes from that person. Essentially, avoid using
anything which anyone who does some research on you might be able to use to narrow
the search space. I would also suggest using as long a phrase as possible. A very
long known quote is probably stronger than a shorter set of random words simply
because the search space is larger.

If you can remember a random set of words, then do that. However, if you can't, then
use a grammatically correct phrase, but make it as long as possible. Remembering the
password is probably as critical has ensuring it is strong. I've frequently found the
weakest part of many systems is their password recovery process and think you should
do as much as you can to avoid ever needing to use such a process. Enter the phrase
in reverse order (or some other pattern you can remember), insert special characters
and numbers into the words, not between them and avoid number patterns such as 2, 4
and 6 digits and stay away from quotes/phrases which someone could associate with
you.


What are the real risks of enabling unsecure DNS updates on Active Directory intranet domain?

When you use secure dynamic updates only the domain members can update their entries. This is achieved by using kerberos to authentificate the client towards the DNS-Server. This authentification funcionality does not seem to be implemented in Linux DNS-Clients and this is why you need to enable unsecure dynamic updates.

Unsecure dynamic updates allow one to update its own DNS record without authentification. This is clearly a threat because DNS is a UDP based protocol and the source address can easily be spoofed on a LAN.

On the other hand this is a very bad documented functionality and there are no tools publicly available that could be used to migrate this attack.

I did never migrate this attack but there are some risks I can think of.

Duplicate Names in DNS Server - Will either result in DoS or prevent a correct functionality of resolving the hostname
WPAD redirection. If you name your host wpad and setup a webserver that provides a proxy configuration you can pass a proxy configuration to internet explorer and chrome users. This is part of the WPAD protocol. The worst thing is that you can force the internet explorer to expose the authentificated users password hash by asking for NTLM authentification. I know its unbelivable but this can also be achieved by NBNS and LLMNR Poisoning using the tool Responder.

// This really got my interest when I got time Im going to write a POC tool that uses this vulnerability.


Should it be dangerous if I revealed part of a raw string of a hash?

For a perfect hashing algorithm there is absolutely no correlation between the input and an output.  Any change in input has a 50% chance of flipping each bit in the hash.  This means that information about any partial part of the plain text leaves no way to guess what the rest of the plain text is.  Even if you have a 500 character string and know the first 499 characters, nothing about the hash will help you determine what the last character is.

Therefore, for a perfect hash, the only way to guess the plain-text is by brute-force.  Of course it's worth a mention that brute force doesn't guarantee that you find the original text - only something that hashes to the same hash.  This is a result of the pigeonhole principle.  This often doesn't matter though.  For instance if you are trying to crack a password, you don't usually need to know the actual password, since any string that generates the same hash as the password will still allow you to login as the user.

Therefore, knowing part of the original text makes brute force easier.  Brute forcing a 10,000 character string hashed with SHA256 is effectively impossible.  However, it's obviously much easier if you know the first 9,999 characters, since you only need to brute force the last one.


Reusing the same session-ID necessarily bad?

Rolling your own session management system is extremely hazardous,  because a lot can go wrong with a session. In PHP you should just use session_start() and the $_SESSION superglobal.

By using the same Session Id each time the user logs in,  then there is no point in changing your password.  There is one token that always permits access.  An attacker could comprise this session with XSS, or due to Insufficient Transport-Layer Security,  and then they will always have access to the system.

Using the same session for every user defeats the purpose, if you need a global state,  use a database


Is the iPhone vulnerable to the BadUSB malware?

It often isn't about reprogramming the firmware of an USB-device/gadget.

You might just create a USB device that looks like a charger, but is an evil device.

Example:

You want to attack a Windows computer with an USB-stick
You get an Arduino Leonardo, which can act as a keyboard, but has the size of an USB-Stick
You program the arduino to output the keystrokes to do  the following things:

Open a command prompt
Activate remote desktop access with password "1234" on command line
Send IP address to the attacker(e.g. by opening a web page on the attacker's server)

This example was for Windows, but because iOS devices also support external keyoard and mouse they might also be vulnerable.

P.S.: Protection against such an attack might be done, e.g. by giving explicit permission for an external device before it is acccepted by the host.


Is there any point in using two step authentication if you have strong passwords?

There are a few benefits that persist in 2FA:

A keylogger can't make use of my 2FA passwords for later.
I can't share my 2FA with somebody on an ongoing basis.
I'm more likely to know my 2FA credentials are compromised (e.g., because my token is missing) than somebody simply copying my sticky note hidden in my wallet.
Somebody who phishes you will be have a limited window during which 2FA will be useful for them and it won't be ongoing.

Controlling the password is usually weaker than the password itself, and that makes 2FA very helpful even with very strong passwords.


How secure is using your fingerprint for password against opportunist thieves?

assuming they do not have access to your finger prints

I belive this assumption is wrong. Fingerprints can be extracted from many things you touch or even from photos.

But let's assume "they" can't do that:

A password is digital. It is exact. If your password is "IiL1l", its trivial to check that it isn't "1iLlI".
Fingerprints are not digital. Every device that validates your fingerprint is only able to compare the scan you make to some model how your fingerprint looks.

This sounds like no big deal, but this has huge consequences. For encrypting things, passwords are converted into keys (using something called a key derivation function). If you change just a single letter of your password, a entire different key is derived. The key is never stored on the device. Every time you decrypt something, the key is derived from your password again. The key is not stored anywhere. Because your password is always exactly the same and the key derivation is deterministic, the key is always the same and decryption works.

For fingerprints, that can't work. Fingerprint sensors work differently, but in the end you always get something that resembles a black and white/greyscale image. Try a simpler experiment: put a single sheet of paper on your desk. Take a camera. Take two pictures that are exactly the same. You won't be able to do that, and for a fingerprint this is a lot harder!

Because of that, it isn't possible to derive a key from your fingerprint.
Your fingerprint and the key are stored on the device. The device checks if your fingerprint looks like the stored one and then releases the key already stored on the device.

Because of this, a fingerprint will always be less secure than a strong password.


Why do some internet banks force logout on back button?

A scenario such banks might want to protect you from could be this:

you visit your banking website and do your banking stuff.
after you are finished you log out and then navigate to some other website to look at cat pictures or whatever.
you leave your computer with the cat picture website open. Because there is nothing incriminating on your screen, you feel safe doing that.
your evil roommate comes along and presses the back button a few times.
they arrive at the cached version of your banking site, see your bank account and see that you still haven't paid your share of the rent even though you clearly have enough money to do that.

That's one reason why banking websites do not work when you navigate to them using the browsers back button.

But an even more likely reason could be laziness on the side of the web developers.

Allowing the user to use back and forward navigation creates an additional variable in a web application which needs to be kept in mind at all times.  Simply making this impossible removes that variable and makes it far easier for the developers to create a secure and bug-free application. Because bugs in banking applications can cause quite a lot of financial damage, developers in that sector are rather conservative and tend to limit usability when it results in a more predictable application use-pattern.


What are the risks of self signing a certificate for SSL

The risks are for the client. The point of the SSL server certificate is that it is used by the client to know the server public key, with some level of guarantee that the key indeed belongs to the intended server. The guarantee comes from the CA: the CA is supposed to perform extensive verification of the requester identity before issuing the certificate.

When a client (the user and his Web browser) "accepts" a certificate which has not been issued by one of the CA that the client trusts (the CA which were embedded in Windows by Microsoft), then the risk is that the client is currently talking to a fake server, i.e. is under attack. Note that passive attacks (the attacker observes the data but does not alter it in any way) are thwarted by SSL regardless of whether the CA certificate was issued by a mainstream CA or not.

On a general basis, you do not want to train your users to ignore the scary security warning from the browser, because this makes them vulnerable to such server impersonation attacks (which are not that hard to mount, e.g. with DNS poisoning). On the other hand, if you can confirm, through some other way, that the certificate is genuine that one time, then the browser will remember the certificate and will not show warnings for subsequent visits as long as the same self-signed certificate is used. The newly proposed Convergence PKI is an extension of this principle. Note that this "remembered certificate" holds as long as the certificate is unchanged, so you really want to set the expiry date of your self-signed certificate in the far future (but not beyond 2038 if you want to avoid interoperability issues).

It shall be noted that since a self-signed certificate is not "managed" by a CA, there is no possible revocation. If an attacker steals your private key, you permanently lose, whereas CA-issued certificates still have the theoretical safety net of revocation (a way for the CA to declare that a given certificate is rotten). In practice, current Web browser do not check revocation status anyway.


How does Blucoat Proxy allow governments to decrypt SSL?

It does not allow governments to decrypt any kind of SSL traffic on any network. BlueCoat is used inside companies (and inside government organizations) to inspect their own incoming and outgoing SSL traffic for malware, data leakage etc. The necessary proxy certificates to do transparent SSL inspection are officially installed on the systems. If these are not installed then users get a warning.


Is emailing a password recovery code as bad as emailing a password in plain text?

No, it's not as bad. Personally, I'm not a huge fan of using email as a password-recovery mechanism just because there are so many "what if"s, but lots of respectable sites do it, so shrug.

The reason it's not as bad is that if you email a password, the attacker will have silent access to the account and the user will be none-the-wiser. And as @drewbenn points out, it also compromises every other site for which the user uses the same password, helps attackers build dictionaries around password patterns (if any), etc. With a recovery code, the code should be one-time use, and the user will know very quickly if it's already been used.


Keeping login in sync with third party providers

If you're using oAuth with Facebook or Google you will be issued an "access token" for the user to access your application. This access token will have an expiry.

Once it is expired, you should use a "refresh token" to ask for another "access token" for the user. If this is not granted, this is when you should logout the user.


Acceptable secure solution to replace static IP addresses for a web application

While you are upgrading the system, you don't want to build the same level of security, but rather, a better level of security. You want to do real authentication, not just IP restrictions.

This can be done by, for example, using hardware security module installed in the workstation. The HSM uses Public Key Authorization to authenticate the machine to the network. Using a VPN (SSL/SSH/IPSec) from the workstation to a gateway machine(s), you form a secure VLAN over the semi secure internal network. The VLAN contains only the systems that are permitted to be accessed from the workstation. Using VLAN, you can control which workstations can connect to which gateway for the secure systems. On top of this, the user can authenticate themselves to the systems they need to access, using traditional username/password and/or hardware token.

IP authentication is for the most part redundant here. The only advantage IP Authentication has over VPN is that IP Authentication is much cheaper to enforce in case of volumetric attack against the gateway. In networks that involves public internet, you always have a risk of volumetric attacks; but in an internal system with mostly semi trusted users, this is usually not something you need to worry about, so I generally would not bother implementing IP auth unless I believe a volumetric attack is a credible attack scenario.


In practice this is likely to be a reasonable protection, but from an ideal standpoint you shouldn't rely on it.  Apart from anything else it disregards the possibility that an attacker can get access to a machine on your local LAN (e.g. if one of your systems gets infected by malware)

In terms of having iptables reject LAN IPs from the Internet, yep this is a standard practice known as Bogon Filtering


What vulnerabilities would this type of "password manager" have?

This password manager have the downsides of making formulas for creating passwords, and lacks the flexibility of a proper password manager.

The most obvious issue is that the passwords are deterministic. It means that if you come across a website that forces you to use exact one digit on the password, you cannot use your password manager to generate it, as you don't control any aspect of the generation process.

The second issue is that you cannot easily rotate passwords. If any of the passwords leaks or expires, you will have to code workarounds for each one.

The last one is that the master password cannot be changed, or it invalidates every single password you have. You have to change every password on every site, and that is bothersome, to say the least.

What could you do? For an experiment, not for real: create passwords using random generator (may it be chars, words, or a mix), encrypt them using a symmetric key, and use the master password to encrypt the symmetric key.

This way you can change any password at will, and encrypt just the changed password. You can change the master password by decrypting the current symmetric key, generating a new master password, encrypting the symmetric key with it, and saving it back.

But unless you are a very talented programmer with a broad knowledge on cryptography and secure programming, don't write a password manager that will be used by anyone but yourself.


Your questions is best answered by the Web Application Vulnerability Scanner Evaluation Project (WAVSEP). Take a look at chapter "3.3 Support for Crucial SSDLC Integration Features".

Concerning automation, the following categories will be most interesting to you, depending on the type of automation you are aiming for:

  Continuous Integration Support (BDD) - support for
  CLI/API/plugin-based scanning through external continues-integration /
  build-management software such as Jenkins. De-facto external support
  for scheduled scans.

  Selenium Import/Integration (TDD) - importing crawling results or
  otherwise integrating with selenium scan scripts.

  Periodic/Scheduled Scans - built-in scheduled scans (also possible
  through continues integration support through CLI/API/plugins)

Exporting results as HTML/PDF is a very common feature. This is not even explicitly mentioned in the benchmark data. I did a quick check for the commercial benchmarked tools and found the following:

AppSpider: HTML
Burp Suite: HTML, XML
Webinspect: PDF, HTML, RAW, RTF, TXT, XLS
AppScan: HTML, PDF
Acunetix: HTML, PDF
Netsparker: HTML, PDF
WebCruiser: no info found

Almost all of the commercial tools support HTML and/or PDF reports. It will be similar with the open source tools, but I leave this exercise to you.


Tor exit node inside the website server to prevent anything in the clear over the wire?

There are three general end-to-end encryption techniques for servers using Tor.
HTTPS
When connecting to a website using HTTPS, Tor does provide end-to-end encryption. This is explained beautifully on the EFF's Tor and HTTPS demo page. When you are using HTTPS, the exit node is not privy to any data going through it because the session key for the traffic is shared only between the client's browser and the destination website's server.

An example of this would be the https://duckduckgo.com/, the DuckDuckGo domain. The session key is known only to your browser and the DDG server. Reading the traffic requires breaking TLS.
Hidden services
This seems to actually be what you are describing. Rather than setting up a website on an exit node (which is public), a website can be created on a server which runs Tor and which is accessible via a particular onion address, allowing the server to be provided with the same anonymity that the client gets. A hidden service is accessible only via its onion name, and the location of the hidden service is hidden from both the client and any other adversaries who may want to pinpoint it. When using a hidden service, traffic never leaves the Tor network.
Connecting to a hidden service involves the client creating a three-hop circuit as normal, but additionally involves the hidden service creating its own three-hop circuit. The client and server agree on a rendezvous point where the third hop in each circuit meet up and exchange data. This allows the traffic to be end-to-end encrypted, even if the hidden service does not provide HTTPS (non-EV certificates are currently not supported for .onion domains). The encryption is provided by the Tor protocol itself, with a key being shared by the client and the server's Tor process.
An example of this is the https://3g2upl4pq6kufc4m.onion/, the DuckDuckGo onion domain. Even without HTTPS, traffic to that site is encrypted by the Tor protocol. There are no exit nodes involved in connecting to a hidden service because no traffic ever exits the network.
Hidden services are now frequently referred to as "onion services". Additionally, a new version of hidden services, version three, has been rolled out. It features a new protocol and longer domain names. The general concept behind v3 hidden services is the same as for v2.
Pinned exit nodes
There is an open proposal to implement pinned exit nodes. This involves a server sending an HTTP header which specifies a particular exit node which the client should from then on use when connecting to the website. It allows websites to run their own trusted exits. The motivation for the proposal is to mitigate man-in-the-middle attacks and promote end-to-end encryption:

Similar to the now-obsolete concept of exit enclaves, this proposal
enables web services to express that Tor clients should prefer a
predefined set of exit relays when connecting to the service.  We
encourage sensitive sites to set up their own exit relays and have
Tor clients prefer these relays, thus greatly mitigating the risk of
man-in-the-middle attacks.

Pinned exit nodes have not yet been implemented.


Is JSON web token further secured in OpenID, and how?

Earlier versions of OpenID don't use JWTs, so in a word: no.

OpenID Connect does not mandate the use of encrypted tokens as it prioritizes adoptability over security. However, it does allow you to optionally encrypt the token as a supported protection.

  ID Tokens MUST be signed using JWS and optionally both signed and then encrypted using JWS and JWE respectively, thereby providing authentication, integrity, non-repudiation, and optionally, confidentiality, per Section 16.14. (Source)

Otherwise, the better way to think of it is that the protocol uses JWT to protect itself, not the other way around.

With that said, the protocol spec does list off a number of considerations. These include mitigations like

using HTTPS
verifying the token is actually signed with the right key
signing token requests
the token should include token restrictions
Blocking open redirects
using a cache to prevent token reuse

And so forth. A lot of these are common sense mitigations that should apply to any number of token-based protocols.


Counterarguments against an anti phishing procedure

As pointed by schroeder, there are many moving parts here, thus many instances where same arguments can be positive or negative.
Here's my argument for one case.
Let the case be: employees of this org share pretty often links via email. Consequently, employees often click and visit links from emails.
From the sender's point of view: after several such messages the sender can likely develop a pattern whether it is better (faster) for her to let it be or "confirm authenticity". In the best case she can "confirm authenticity" every time using a mental shortcut if this is possible. That is, a no-brainer to make her request acceptable asap. Let's suppose she has to "confirm authenticity" by filling a one-line form with her judgement of authenticity. Having worked in a SOC and completing many tickets, my colleagues and I developed standard "fillings" to copy-paste without thinking, because thinking is expensive.
This sender scenario looks okay from a security POV and okay-ish from a usability POV to me.
The worst case sender scenario is that she will ignore the confirmation and let the email be sent with the warning message.
This sender scenario looks the same from the security POV and little worse from the usability POV (receiving bot emails).
Let's look at the receivers' scenario.
Receivers are used to often click and visit shared links via email.
In the best case scenario, the links are vetted and authenticated.
This seems ok. However, a question arises on how they perceive this mechanism (if they know about it). Usually, the organizational infrastructure is perceived as secure, so they mainly feel safe on clicking links at work. If they know this mechanism is in place, this may reinforce this perception. This is not great if they whole system will not work in the end. But it is neutral in case it works IMO.
In the worst case receiver scenario, all (many) links were flagged as potentially dangerous causing the warning to be displayed all (many) times. This is bad.
It is bad, because the habituation to repeated and ill-perceived warnings is notoriously a big problem in human computer interaction and still not solved, as reviewed here,here. This means that the receivers are likely to get used to ignore the message, they may literally become blind to it (cognitively speaking). Thus invalidating the whole system. This is bad from both security and usability POVs.
So, we have covered the extremes of one possible case: the case of the org with lots of link sharing.
The positive extreme is where senders always "confirm authenticity" and receivers do not perceive an "improved security". There is some burden on the sender's side from the usability point of view. No burden for receivers, though. On the security side, external/untrusted links are going to be flagged. Depending on the ratio of # of rusted/un-trusted shared links, e.g. trusted >> un-trusted, this may result in a positive outcome for security.
The negative extreme is where senders never "confirm authenticity" and receivers (almost certainly) will ignore the warning message. It follows that the same "security level" is kept, but usability is worsen on both sender and (even more) receiver.
Of course there is a continuum between the extremes, and if that continuum is measurable (e.g. how many trusted/un-trusted links are sent in time), chances are that a data-driven decision can be made. If not, maybe a testing period with control groups may be relevant to measure that.


No, afaik.

Also, if it is supposed to be readable and helpful for non-tech people, each translation might be a book for itself, explaining each part of those strings, it's up- and down sides in painful detail.

Just in case you didn't know, rfc 5246 currently covers this format and includes a table with cipher suites that might send you down a helpful track.

Your example

  TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384_P384

means "TLS using ECDHE_ECDSA with the elliptic curve P384 for key exchange, encrypting the connection using AES_256 in GCM while using SHA384 as PRF."

As you can see from following the links, there is no 'easy' understanding of the used acronyms themselves. Yet the general syntax is

  TLS_nameOfKeyExchange_WITH_nameOfBlockCipherAndMode_nameOfPRFForMAC_addinionalExtensions

As you see from my edit, the inference sometimes fails horribly, too;)


I presume you're referring to an OAuth 2.0 Implicit Flow.

I think you're wondering why you need to direct away from your SPA for the user to authorize your app (by logging in, and usually selecting permissions to grant your application).

OAuth, as a protocol, is designed to allow a third-party to authenticate a user's identity. To use Google OAuth as an example, the user leaves your site and goes to Google, so that you can't steal their password or perform other actions on the user's behalf. They've left your site and entered the site of their trusted identity provider, who you are also implicitly trusting by allowing them to authenticate your user's identity.

If you are authenticating with your own server, there may be no need to use the OAuth protocol. Just allow them to submit their username and password directly. They're already trusting you to handle their username and password by signing up for your service.

The only good reasons I'm aware of to use your own OAuth provider on your site are:

Centralizing identity in a micro-services architecture
Exposing an identity provider for third-parties to use
Using a pre-packaged software solution as an identity provider, so you don't have to roll your own identity and authentication solution

Edit: Here's a a better resource on implicit flow. RFC 6749 Section 4.2

And here's an ascii-art diagram of how the implicit flow works. Note that the authorization server is distinctly a separate entity in this diagram, and that the authentication step is directed toward this server.

 +----------+
 | Resource |
 |  Owner   |
 |          |
 +----------+
      ^
      |
     (B)
 +----|-----+          Client Identifier     +---------------+
 |         -+----(A)-- & Redirection URI --->|               |
 |  User-   |                                | Authorization |
 |  Agent  -|----(B)-- User authenticates -->|     Server    |
 |          |                                |               |
 |          |<---(C)--- Redirection URI ----<|               |
 |          |          with Access Token     +---------------+
 |          |            in Fragment
 |          |                                +---------------+
 |          |----(D)--- Redirection URI ---->|   Web-Hosted  |
 |          |          without Fragment      |     Client    |
 |          |                                |    Resource   |
 |     (F)  |<---(E)------- Script ---------<|               |
 |          |                                +---------------+
 +-|--------+
   |    |
  (A)  (G) Access Token
   |    |
   ^    v
 +---------+
 |         |
 |  Client |
 |         |
 +---------+


DDoS (Distributed Denial of Service) attacks are at their core near identical to perhaps more common DoS (Denial of Service) attacks, with one major difference in DDoS being, well, distributed. What that means though is that the attacker(s) will use multiple locations as a source of their attacks on your infrastructure, but more importantly, just like with DoS attacks, the attacker(s) will in both cases try to exhaust your infrastructure's resources. This is where booth DDoS and DoS might be the same, and is important to understand.

So, exhausting your infrastructure resources. What could that mean and how would an attacker do that? It turns out there are many ways to cause servers and other networking equipment to have more work with preparing and responding to external requests, than the attacker's own setup (distributed or not) would permit. So this is where the attacker takes the advantage - it is cheaper for him to send requests, than for you to respond to them. Given enough attack oomph by whichever means, one stronger adversary (DoS), or many weaker but greater in number ones (DDoS), your server's resources will be exhausted and cause denial of service to any other, legitimate traffic. Some of these techniques would be traceable to the individual Virtual Host responding on a certain HTTP(S) location, and others might rather target the infrastructure more directly and on lower levels, maybe the transport layer itself by abusing network protocols, both causing too many responses to be required than the infrastructure can handle.

So here's are two clues here:

The DDoS attack your provider mentions had to have been on the high level stack that would identify a virtual server in its requests, like for example on the HTTP(S) stack and requesting URLs pointing to your virtual server, and
Whichever resource was continuously requested caused the server your Virtual Host was hosted on to exhaust its resources by preparing a response. That could be any of the number of resources your VPS server had a limited supply of, or any of their combinations, like maybe continuously reaching local storage quota, system's memory, CPU cycles, e.t.c.

This might seem clear cut, but bear with me, because it really isn't in your case. Here's the thing; You mention you hosted your website on a VPS (Virtual Private Server), so in theory, all the resources your VPS server could have exhausted shouldn't have translated to any problems with other VPS's on the same physical hardware hosting them (i.e. it's supposed to be a Virtual Machine and isolated from any other VM's) and you have actually been paying to your provider maybe a monthly fee to use all those resources to your liking, as long as you're respecting their ToS (Terms of Service). And for any DDoS attempts to have directly identifiable target on this VPS/VM stack, their requests would have to be on the highest stack actually requesting a network domain (let's say it was on the HTTP(S) protocol, which would make it URLs then, for the sake of argument) and including enough information for the VM host to decide to which VM client (your VPS) to redirect requests to.

So we have this conundrum of either/or:

If the problematic requests were on the HTTP(S) stack and including identifiable request URLs, then this shouldn't cause any problems to your VPS host, but it would exhaust your VPS resources, something that you were paying for anyway, and
If the problematic requests were on the lower, network layer on the TCP/IP stack, then they wouldn't necessarily (and why would they?) include information in the request packets which specific VPS client they were targeting.

So this can only be answered in two ways:

Your VPS was actually the only VM that was hosted on the same IP address, and your provider could conclude your services were a target of DDoS attack like so, or
Your VPS provider is full of s***

Most likely though, you will never know which one of the two options was really the case. If it's all the same to you by now, you can post your IP and domain name in the comments below, and I'll check if there are any conclusive indications to be found in the various databases / resources on the Internet which of the two options might be more likely, but unless you get a full disclosure by anyone with direct access to the physical server in question, it will remain a mystery. It's up to you to decide, if you can deal with such unknowns and how much you're prepared to pay monthly to have this service, but I know which route I'd choose. Just saying... ;)


Can location/owner of mobile phone be identified

Well, that is hard to answer. He should not be identifiable by the GSM internet connection thanks to the VPN, but the native Facebook/Messenger app will almost certainly identify him by grabbing data of his phone if allowed. Facebooks core business is gathering data about people and they do not shy away from that with their apps. They try to grab all contacts, phone number, GPS position, SMS and just generally everything they can get their hands on.

If you want to remain anonymous/pseudonymous I would strongly recommend avoiding Facebook if at all possible. If not, there is an opensource app that allows access to Facebook and tries to not reveal private information that is not voluntarily provided. It may or may not be successful at preventing identification of the user.


Is HTTPS required for local network server to server communication

The answer to your question comes down to threat modeling. Using cryptographic protocols like HTTPS is a security mechanism to protect against certain threats. If those threats are relevant for you, must be analyzed:

Are there potential threat actors in your internal network? Based on your question you seem to assume that the internal network can be fully trusted. This is often a misconception, because there are several ways your internal network can be compromised (e.g. valid users with access to this network are turning malicious, a systems in this network gets compromised, a misconfiguration opens up the network segment, etc.).
Will the architecture be subject to change? It is likely that the system will change over time and prior security assumptions (e.g. my internal network is trusted) no longer hold. If that's a reasonable scenario, it might be a good idea to build the necessary security mechanism in in advance. That's what security best-practices are for. Providing security in an area of uncertainty.
Is there a regulatory, legal or compliance requirement that must be fulfilled? You said that your customer considers HTTPS to be state-of-the-art / modern best-practice. The source of this friendly worded statement might actually be an externally driven requirement, that must be fulfilled. Non-compliance is a threat that should also be covered in a threat analysis.

Those are important topics worth analyzing. When I design system architectures and I am in doubt, I prefer to err on the side of security. In this case the best-practice approach is indeed using HTTPS for communication, no matter the circumstances, as long as there are isn't a considerable impact on the application (e.g. performance impact).

Difficulty to maintain server certificates shouldn't be a problem nowadays, as this is common practice. This should be part of normal scheduled operations activity.

Having said all this, there is of course additional effort required to use HTTPS instead of HTTP and it is your right to charge the customer for this additional effort. I suggest you calculate what this will cost during development and over time during operation and let the customer decide if the cost is worth the benefit.


Would it make sense if WiFi portals had a password to connect to the wifi too?

If an attacker is able to access a wifi network (either an open one, or has the security key for it),  he or she is able to see all of the traffic that is being sent to other users on that network segment, even if he or she is not connected (associated) with the access point.  Additionally, the attacker may also be able to perform a Man-in-the-middle or Man-on-the-side attack where he/she is able to alter the data that is sent to the victim's machine.

Adding the encryption key only adds security if the attacker does not know it.  Once the attacker has it, it's basically the same as an open wifi network.


One security problem with your approach is that everything that you are hashing may potentially be guessable.  As a result, tokens may be guessable.

A simple fix is to generate the token randomly: use a random 128-bit string from a cryptographically random source (e.g., /dev/urandom or CryptGenRandom) to form a single-use token.  Store the token in the database along with information about the desired action, and when you receive a request, if it contains a token found in the database, take the action suggested by that database entry and delete the token.  If you take this approach, don't include anything like item ID, item type, etc., in the URL.  Instead, store that in the database.

Alternatively, you could include some unguessable secret (e.g., a 128-bit cryptographic key) as part of the input to the hash function.  When you receive the request, you'll need to recompute the hash function (using the parameters in the request) and make sure the provided token is correct.  Make sure that all of the parameters in the URL are included as part of the input to the hash function (otherwise someone could change that parameter without invalidating the token).

As @AaronS notes, if someone forwards the email, then the recipient of the forwarded email learns the token.  Thus, this scheme is not perfect.  For some uses (e.g., unsubscribing), it may be good enough.  For others (e.g., managing access to an online banking account), it is not a good choice.


How much of a risk to students is an open WiFi network on campus? EDIT: please read in full.

I think you are worrying about the wrong thing.  You should have no reason to trust the local network any more than you would for any data you'd send over the public internet.  If you want to send a password, it's your responsibility to ensure you're using a connection protected by TLS.  Trusting the local WiFi to protect your data is essentially excluding only the hackers within eyesight, and thinking that somehow keeps you safe.

You are responsible for your security on your own machine, and any network connections you make.


How to determine source of e-mail and verify if the source is/could be legitimate?

To find the source of an email, you need to look at email headers. In Gmail, click the down arrow next to the reply button, and choose "Show Original". If you use a different email program, check this list, or use Google.

In general, the bottom-most "Received:" line indicates the source of the email. This isn't 100% reliable, but is good enough in most cases.

Here is an example (from http://whatismyipaddress.com/email-header) showing that the email sent to example_to@imaps.bath.dc.uk originated from 205.206.231.19.

  Received: from tom.bath.dc.uk ([138.38.32.21]
  ident=yalrla9a1j69szla2ydr)
          by steve.wrath.dc.uk with esmtp (Exim 3.36 #2)id 19OjC3-00064B-00
          for example_to@imaps.bath.dc.uk; Sat, 07 Jun 2005 20:17:35 +0100

  Received: from write.example.com ([205.206.231.26])
          by tom.wrath.dc.uk with esmtp id 19OjBy-0001lb-3V
          for example_to@bath.ac.uk; Sat, 07 Jun 2005 20:17:30 +0100

  Received: from master.example.com (lists.example.com [205.206.231.19])
          by write.example.com (Postfix) with QMQP
          id F11418F2C1; Sat, 7 Jun 2005 12:34:34 -0600 (MDT)

I strongly hold the view that the most reliable way to verify if an email is legitimate is to contact the (purported) sender via a different method, and ask them. Technical analysis of the headers might indeed show that an email came from company X, but what if the sender had his account hacked? Doing this also alerts the sender of a breach, if it has occurred, doing them a great service.

Finally, good that you didn't click the link - clicking on unknown links in suspicious emails is risky. There are some tools to help you evaluate a link without visiting it - I find URLquery and VirusTotal to be very good. Others may have additional suggestions.


Is it safe to rely on text messages as a means on authentication?

In my opinion SMS messages for two factor authentication is not a secure design decision compared to other alternatives.

SMS messages are vulnerable to a number of scenarios:

Malware on the smartphone, the vast majority of users don't check permissions so it's reasonable to assume malware creators could quite easily access SMS. This is especially a problem if the attack against the password originated from the phone too (such as via a phishing app).
GSM can potentially be compromised

An alternative which is superior in pretty much every way is TOTP, where basically the user encrypts the time rather than the service having to send something to the user. This way absolutely no communication needs to be made with the 2FA device, and can effectively be used offline.

Google Authenticator is one popular implementation.


chrome is launched and tries to open a wierd website

how can I get rid of this?

You need to uninstall Chrome immediately, run a full AV scan (including searching for rootkits), and only after re-install chromium. Some mining scripts use JavaScript within your browser to mine - it sounds like this is what's happening.

  I also need to know which process fires chromium?  is there a way to tell what process is the cause of firing another process?

This may help. It does require downloading other software. If you're not comfortable with that, try using the process manager and checking the startup programs.


Is disabling IPv6 an effective workaround for "Bad Neighbor" Vulnerability (CVE-2020-16898)?

Probably disabling all the IPv6 stack is not a good idea, specially if you have applications that use IPv6. On the other hand, you have the source code of a tool that can generate the issue, so my recommendation is to block that traffic on the host firewall if possible, other option will be disable RA packets, but that depends on your operating system.
If you can not block the traffic probably the only option that you have is to disable the IPv6 stack.


What are the Consequences of OpenPGP Key Collisions?

You have to distinguish between different kinds of attacks which are in scope of the hash sum algorithm chosen.

The post you referenced on one hand discusses collision attacks (against the whole SHA-1 based fingerprint).

  However, since PGP keys are usually generated by their users, collision attacks are not a problem. They might conceivably be a problem in contexts where someone's key is generated by a third party, which might occur in some corporate environments or other large organizations.

A collision attack means finding two (or more) keys with the same fingerprint. As long as you create your key own your own, this is not an issue -- all you could do is create two keys with the same fingerprint, but they all belong to you anyway. If somebody else creates the key for you (for example, your company), they might be able to perform a collision attack and hand over one key with a given fingerprint while keeping another key with the same fingerprint -- but they might keep the private keys anyway, so there's no need to perform such sophisticated attacks.

A collision attack is simpler/faster to perform as a preimage attack, as you've got more control over the input and can find arbitrary two keys with matching fingerprint instead of having to find a collision for a given, fixed key.

  Preimage attacks on SHA-1 could be a problem, if one only relies on the fingerprint. I can imagine various scenarios where an attacker could fool someone into accepting their key in place of another key. Alice downloads a key from somewhere and calls Bob to verify the fingerprint. An attacker organizes a keysigning party and substitutes their key for someone else's. Such attacks would be difficult, but feasible.

The result is that an attacker would have another key with the same fingerprint. Such a preimage attack would probably fool a bunch (if not most) of OpenPGP implementations in considering the wrong key.

A very relevant, but different attack is a collision attack on short key IDs. Short key IDs are 32 bit subsets of the fingerprint, and have a much too small value range. Those are actually a kind of preimage attacks, as they allow to collide key IDs against existing keys. The solution is not to use short key IDs at all.


It is secure to use the shared secret as the key for a HMAC? is it
  better to derive one key for all of the messages that are going to be
  HMACed or a key for each message?

As long as you use the key solely for HMAC, you can use single key for multiple messages safely. Many authentication protocols that issue tokens use one key for signing multiple tokens. JWT is one such example. .NET has it's own implementation.

But please note that in case you need to encrypt and then HMAC the message, you need to use two different keys. It is possible to derive these two out of a single, shared master key. See this and this.

There is a better approach though. You can use GCM mode for encryption which will do exactly what you need with a single shared key. Make sure you use it properly, especially concerning the IV. Study it's disadvantages too and see if they concern you.

  Is it safe to use the shared secret as the key for the symmetric
  encryption after the shared secret has been exchanged using PKI?

Yes, this is an approach used in SSL/TLS for example.


Trustable Sources For Security Algorithms and Standards?

There is no central repository from where to get this kind of source.

What you should do, is to get the official publication of any standard you want to refer too. You can either find it by yourself, with a search engine, or by reading other article that cite this particular standard.

A lot of protocols are RFC, published by the IETF.

Good Wikipedia articles usually reference the main paper in its sources.


Blocking network access to host(s) at the kernel level in Linux?

Filtering arbitrary connections could be done with a kernel module by hooking netfilter.  And anything done in kernel land with a kernel module,  can be undone with a kernel module.  Also,  nothing is keeping root form just installing their own kernel...

root is GOD,  never forget that.


EICAR should work on any file name or extension. It is intended to be placed into a .COM file in the first place.

For Microsoft Office files, your best bet is to add a bunch of VBA macros in that try to create files with .exe extensions and write junk (perhaps EICAR) into them. For newer (e.g. xlsx, docx) files the format is just a ZIP, so you can also include EICAR into there as an embedded file too.

For PDF files you could use one of the known exploits for PDF readers, but make the payload benign. There's a decent-ish tutorial here on how to generate PDF exploit payloads with Metasploit.


Is it safe to install MS17-010 unpatched OS as guest on patched host?

If the guest is unpatched and has the vulnerability present then yes it is vulnerable. If the guest has any of its interfaces NAT’ed or Bridged to an unprotected network then the guest is exploitable via WannaCrypt.


Information leakage through json response

If there is unauthorised access to data due to the way the process is designed, then that, by definition is "data leakage".

There might be no impact by having the data leaked, depending on the type of data, or the designers might have classified the access type as effectively "authorised" because they deem it "public data", but that's a separate issue and a separate assessment.

If you can show that there is a negative impact to this leakage, then the severity increases. For instance, knowing the age, location, demographic survey questions, and order history would be enough to trigger many jurisdiction's data privacy laws (because it might be enough to uniquely identify someone). But that's situational and requires some context to assess.


The sent gmail was modified to other version, how to trace the record beside header?

the emails I sent from gmail were either modified or the documents got
  replaced for others

Where do you see the modification? In general, email does not guarantee the integrity of the messages, you need to digitally sign them to have this feature.

If you see the modifications on your Google account then someone has signed in with your credentials or used your device.

If you see the modification at the receiving end than either the receiveing end has modified the content or someone on the way (not likely).

  Also, when i see the devices in recent activities, I see a WINDOWS
  PHONE which is not my device, but google has only advised me to change
  the password.

Changing the password is not enough if the new password leaks somehow (for instance via a keylogger or someone spying at you). You need to enable multifactor authentication. In that scenario, someone having your login and password will not be able to log in from a new device - they will be required to also provide a number which changes every minute.


What is the impact of leaked recaptcha secret key?

Not the answer I would have guessed, but:
In this particular case there is no impact.
Which seems like a bold statement for a leaked secret key, but in this one case I believe the warning about not leaking the secret key is more about best practices than actual concern.  Since that is a rather unusual answer, I'd like to break down the things that would normally be a concern and explain why they aren't applicable here:
1. Circumventing the captcha verification
This is obviously a primary concern - if the leaked captcha secret key allows an attacker to circumvent the captcha protection, then you have a serious problem.  However, the way the recaptcha flow works makes this impossible.  Most importantly, the verification is done by sending the user's response to a google API (using the secret key) and checking for confirmation.  Moreover, the response can only be checked once specifically to prevent replay attacks.  This simply leaves no room for an attacker with a secret key to place themselves in the middle and fake a confirmation.  It's really as simple as that.
2. Broad access credentials
In many cases a single key can be used to authenticate for multiple services.  You could imagine a secret key that is used not just for recaptcha but also for other administrative tasks in the google cloud system.  Leaking such a key would be very dangerous, as it would potentially have a nearly limitless impact.
As it turns out though, the keys for recaptcha seem to be limited only for use in the recaptcha system.  Apparently this is a little bit isolated from other google services, and it doesn't appear possible to create a key that is used for anything other than recaptcha.
3. Use of paid services
If you pay for a service based on usage, then gaining access to the secret key effectively gives someone the ability to use the service and make you pay for it (although in this case you would also have to have a permissively configured public key).  Of course this service is free, so that doesn't help anyone.
4. DoS through rate limiting
This one may be a concern, although I don't think so.  Many free google services have rate limiting to prevent excessive usage, or to move you to a paid tier depending on your usage level.  If the verification endpoint is rate limited than an attacker with your secret key could spam the endpoint fast enough to effectively DoS the key, preventing your service from verifying captchas.  The impact that this has depends on how your service handles rejected verification attempts.
However, I don't see any mention of rate limits in the documentation.  This doesn't necessarily mean there is no limit, but if there isn't a limit then this attack definitely isn't possible.
Summary
It's possible I missed something, but I believe that for a recaptcha secret key there is no actual impact due to a leak.  I would still follow the suggestion and keep it secret.  It's always best to practice best practices.


Can cascaded routers protect inner network's machine from attacker from outer network?

I presume that by "router", you mean each of these is a "router/NAT/firewall" combination appliance.  Most home routers include firewall capabilities, which is most likely what you're relying upon here.  (Note that NAT is a connection sharing technology, but not a defense mechanism.)

To directly answer your question, if a hacker gets inside your first router A, the answer is "yes."  He could install network monitoring software (such as wireshark) on machine A.  He would then have a couple of options to get the traffic into machine A to be monitored.

He could reconfigure router A to mirror all LAN traffic to the hardware
port where Machine A is located (a common task when installing a
network monitoring device; many routers and switches support this.)
He could reconfigure your router A to act like a hub, automatically mirroring all LAN network traffic to all ports (may be possible with some cheap consumer routers.)
He could configure machine A to act as a router.  He could install and run DHCP on machine A, assuming router B is getting its external address via DHCP it could respond that its gateway is 10.10.0.10 (machine A's address.) That way all traffic from network B would be routed through machine A, where it would be subject to monitoring.

This would only give the attacker the capability of monitoring unencrypted traffic; but it still would not permit him to decrypt the contents of https/TLS/SSL encrypted streams.  It would also not permit him to see LAN traffic inside router B, so if you were printing from machine B to another printer on the 192.168.10. network, he would not be able to capture it.  (At least not without breaking into router B.)


Disclosure: I work for one of vendors participating in NoMoreRansom.

Most modern ransomware indeed implements proper cryptography. Earlier versions were using rand() for key generation, seeding the random generators with variants of time() - this is why it was important for successful decryption to know when exactly the infection happened; ideally down to minutes. Those could be decrypted with brute force. But most modern ransomware indeed uses either Windows Crypto API, or bundled crypto libraries.

However, no matter how correctly ransomware is implemented, there is always a weak point - to facilitate decryption, the key(s) have to be stored somewhere. This location could be traced by security companies, who would work together with law enforcement to take it over. Access to the server gives the security company the ability to decrypt the ransomware victims files. This is for example the case with GangCrab ransomware.


Can an attacker make POST or PUT request if he knows CSRF token?

Assuming the target website have a permissive cross origin resource sharing configuration or you found XSS on the target website (I guess it's how you got that token from), you could just make an AJAX request specifying your custom XSRF header.

$.ajax({
  type: "POST",
  beforeSend: function(request) {
    request.setRequestHeader("XSRF-Token", yourToken);
  }
 [...]


If someone asks to borrow your phone to make a call, what could they do?

A few scams I've seen making the rounds:

Use it to dial a premium rate number owned by the group. In the UK, 09xx numbers can cost up to £1.50 per minute, and most 09xx providers charge around 33%, so a five minute call syphons £5 into the group's hands. If you're a good social engineer, you might only have a 10 minute gap between calls as you wander around a busy high-street, so that's £15 an hour (tax free!) - almost triple minimum wage.
Use it to send premium rate texts. The regulations on there are tighter, but if you can get a premium rate SMS number set up, you can charge up to £10 per text. A scammer would typically see between £5 and £7 of that, after the provider takes a cut. It's also possible to set up a recurring cost, where the provider sends you messages every day and charges you up to £2.50 for each one. By law the service provider must automatically cancel it if they send a text sayin STOP, but every extra message you send gains you money.
Set up an app in the app store, then buy it on peoples' phones. This can be very expensive for the victim, since apps can be priced very high - some up to £80. In-app purchases also work. This is precisely why you should be prompted for your password on every app purchase and in-app purchase, but not all phones do so!
Install a malicious app, such as the mobile Zeus trojan. This can then be used to steal banking credentials and email accounts. This seems to be gaining popularity on Android phones.


Trusted Timestamping Scope and Real-World Uses

Time stamping is meant to provide a verifiable proof that a given piece of data "existed" at some past date. One widespread time stamping protocol is described in RFC 3161: technically, the TSA (Time Stamping Authority) computes a digital signature on a structure which includes the current date (at the time of signature, as known by the TSA) and a hash value computed over the data which is to be time-stamped. The time stamp is a "proof" in a legal sense as long as there are mechanisms with appropriate legal value that guarantee that the TSA has a correct source for the current date and time, that its private key is properly protected and never used to sign fake time stamp structured, and that the purported TSA public key (used to verify the time stamp) is really the genuine key owned by the TSA. PKI may be involved.

A simple use of time stamping is to establish a proof of anteriority: the digital equivalent of a Soleau envelope. Time stamping is also a critical component of long-term archival of digitally signed data: digital signatures tend to "expire" (because, generically, the validity of a digital signature, as a kind of proof, depends on the continuous exclusive control of the private key by the signer, which is hard to maintain for extended period of times -- thus, certificates have an "end of validity" date). See ERS and CAdES for examples of how time stamping is used in such a context.

Legal frameworks on time stamping vary, depending on the country. In France, there is a state-managed registry for time stamping authorities and systems which can be viewed as a kind of diploma for TSA who "do it right" (in a very French, state-centralized way).

Authenticode can embed time stamps. PDF files can also be time stamped in a way which is already supported by Acrobat Reader, along the PAdES format (a PDF equivalent of CAdES).