Is any systematic method that can detect weak cryptographic algorithm in source code

First of all, md5 is a hash function, not an encryption function.

As to hash functions that are considered broken:

There are only a few - a simple egrep might spit out some offending source files given the right expression.
As to ciphers:

strong ciphers:

As this recent question demonstrates, most of the time the problem is not the actual encryption used but that it is used in the wrong way, without sufficient understanding of the matter.

This cannot be detected sufficiently good, because the problems are often introduced in a very subtle way, where e.g. only the variable names hint at a problem.
weak ciphers (or weak modi, like ECB) may be put on the same black list string file that is used to search for md5 et al.

Secondly, as I come to think of it: md5 has legitimate use cases other than secure hashing (which it is not quite as good in).

Also, you say

  Weak cryptographic algorithm should be removed from source code to avoid a false sense of security

wich I not quite get: where does the false sense of security come from? End users rarely look at sources - and if they do, they most likely can spot what you could detect very quickly. The developers of the sources should know better. If that is a problem, you rather want to educate the developers than scanning their sources for weak crypto use.


What is the Poodle vulnerability ?

The "Poodle" vulnerability, released on October 14th, 2014, is an attack on the SSL 3.0 protocol. It is a protocol flaw, not an implementation issue; every implementation of SSL 3.0 suffers from it. Please note that we are talking about the old SSL 3.0, not TLS 1.0 or later. The TLS versions are not affected (neither is DTLS).

In a nutshell: when SSL 3.0 uses a block cipher in CBC mode, the encryption process for a record uses padding so that the data length is a multiple of the block size. For instance, suppose that 3DES is used, with 8-byte blocks. A MAC is computed over the record data (and the record sequence number, and some other header data) and appended to the data. Then 1 to 8 bytes are appended, so that the total length is a multiple of 8. Moreover, if n bytes are added at that step, then the last of these bytes must have value n-1. This is made so that decryption works.

Consider the decryption of a record: 3DES-CBC decryption is applied, then the very last byte is inspected: it should contain a value between 0 and 7, and that tells us how many other bytes were added for padding. These bytes are removed, and, crucially, their contents are ignored. This is the important point: there are bytes in the record that can be changed without the recipient minding in the slightest way.

The Poodle attack works in a chosen-plaintext context, like BEAST and CRIME before it. The attacker is interested in data that gets protected with SSL, and he can:

inject data of their own before and after the secret value that he wants to obtain;
inspect, intercept and modify the resulting bytes on the wire.

The main and about only plausible scenario where such conditions are met is a Web context: the attacker runs a fake WiFi access point, and injects some Javascript of their own as part of a Web page (HTTP, not HTTPS) that the victim browses. The evil Javascript makes the browser send requests to a HTTPS site (say, a bank Web site) for which the victim's browser has a cookie. The attacker wants that cookie.

The attack proceeds byte-by-byte. The attacker's Javascript arranges for the request to be such that the last cookie byte occurs at the end of an encryption block (one of the 8-byte blocks of 3DES) and such that the total request length implies a full-block padding. Suppose that the last 8 cookie bytes have values c0, c1, ... c7. Upon encryption, CBC works like this:

So if the previous encrypted block is e0, e1, ... e7, then what enters 3DES is c0 XOR e0, c1 XOR e1, ... c7 XOR e7. The ei values are known to the attacker (that's the encrypted result).

Then, the attacker, from the outside, replaces the last block of the encrypted record with a copy of the block that contains the last cookie byte. To understand what happens, you have to know how CBC decryption works:

The last ciphertext block thus gets decrypted, which yields a value ending with c7 XOR e7. That value is then XORed with the previous encrypted block. If the result ends with a byte of value 7 (that works with probability 1/256), then the padding removal step will remove the last 8 bytes, and end up with the intact cleartext and MAC, and the server will be content. Otherwise, either the last byte will not be in the 0..7 range, and the server will complain, or the last byte will be between 0 and 6, and the server will remove the wrong number of bytes, and the MAC will not match, and the server will complain. In other words, the attacker can observe the server's reaction to know whether the CBC decryption result found a 7, or something else. When a 7 is obtained, the last cookie byte is immediately revealed.

When the last cookie byte is obtained, the process is executed again with the previous byte, and so on.

The core point is that SSL 3.0 is defined as ignoring the padding bytes (except the last). These bytes are not covered by the MAC and don't have any defined value.

TLS 1.0 is not vulnerable because in TLS 1.0, the protocol specifies that all padding bytes must have the same value, and libraries implementing TLS verify that these bytes have the expected values. Thus, our attacker cannot get lucky with probability 1/256 (2-8), but with probability 1/18446744073709551616 (2-64), which is substantially worse.

I use [product]. Am I affected? Is [product] vulnerable to the Poodle attack ?

The attack scenario requires the attacker to be able to inject data of their own, and to intercept the encrypted bytes. The only plausible context where such a thing happens is a Web browser, as explained above. In that case, Poodle is, like BEAST and CRIME, an attack on the client, not on the server.

If [product] is a Web browser, then you may be affected. But that also depends on the server. The protocol version used is a negotiation between client and server; SSL 3.0 will happen only if the server agrees. Thus, you might consider that your server is "vulnerable" if it allows SSL 3.0 to be used (this is technically incorrect, since the attack is client-side in a Web context, but I expect SSL-security-meters to work that way).

Conditions for the vulnerability to occur: SSL 3.0 supported, and selection of a CBC-based cipher suite (RC4 encryption has no padding, thus is not vulnerable to that specific attack -- but RC4 has other issues, of course).

Workarounds:

Disable SSL 3.0 support in the client.
Disable SSL 3.0 support in the server.
Disable support for CBC-based cipher suites when using SSL 3.0 (in either client or server).
Implement that new SSL/TLS extension to detect when some active attacker is breaking connections to force your client and server to use SSL 3.0, even though both know TLS 1.0 or better. Both client and server must implement it.

Any of these four solutions avoids the vulnerability.

What do I need to do to secure my [product] with respect to this vulnerability?

Same as always. Your vendor publishes security fixes; install them. Install the patches. All the patches. Do that. For Poodle and for all other vulnerabilities. You cannot afford not to install them, and that is not new. You should already be doing that. If you do not install the patches then Níðhöggr will devour your spleen.

How do I detect Poodle attacks on my network?

You don't ! Since the most probable attack setup involves the attacker luring the victim on their network, not yours.

Although, on the server side, you may want to react on an inordinate amount of requests that fail on a decryption error. Not all server software will log events for such cases, but this should be within the possibilities of any decent IDS system.

Are there any known Poodle attacks?

Not to my knowledge. In fact, when you control all the external I/O of the victim, it is still considerably easier to simply lure the poor sod on a fake copy of their bank site. Cryptographic attacks are neat, but they involve more effort than exploiting the bottomless well of user's gullibility.


Types of attacks outside of AppSec and Vendor-Specific Systems?

See the CAPEC-1000, a very large list of attack mechanisms. Click "Expand All" to see them all.

Not all of these mechanisms are specific to the web, but they are applicable nevertheless.


decrypt a string with a password, but unknown method

Easy way:

Write a script that tries decryption with openssl using all of the block cipher modes. I would consider using openssl in a BASH script or importing pyOpenSSL (or subprocess) and using try/except blocks in python (or the equivalent in whatever language you are most comfortable in) to get the right mode quickly.
Academic way:

Write a detection oracle.
If you have not read through the Matasano Crypto Challenges before, I would recommend starting at Set 1 and reading about implementing and detecting ECB. Set 2 goes into implementing/detecting CBC and also creating a CBC/ECB detection oracle. Once you understand how the block cipher modes work, it becomes easier to understand how to differentiate them from eachother.
Unfortunately this is where my knowledge currently gets hazy on the subject, so if an ECB/CBC detection oracle does not identify the ciphertext, I would suggest you take a look at this good answer to a similar question. The user explains what you would need to look for in order to identify OFC/CTR and EAX/GCM as well, which you could then use to create a more complete detection oracle.
Update 9-Mar-2016
I have been trying to tackle the problem of identifying block cipher modes of encryption, given ciphertext-only, over the last week. The problem with the answer I referenced (in relation to this goal) is that it assumes knowledge of the key/IV to be able to analyze error propagation. I have read through every cryptography book I own, searched the interwebs, and have asked a question specific to this on crypto.SE. From this research so far, I have tentatively come to the conclusion that:

ECB can be easily and consistently identified, given a ciphertext of a large enough size.
Stream Ciphers (CFB, OFB, CTR) can easily be identified if the ciphertext is not an appropriate block length, however I have yet to find a way to differentiate stream ciphers from each other given ciphertext-only.

With this information, a ciphertext of block length (AES=128) can be assumed with ~99.22% certainty (1/128 chance of stream ciphertext being multiple of blocklen = ~0.78 chance) to be a block cipher. From here, the aforementioned detection oracle will be able to detect ECB if it is used. If ECB is not detected, you are left with CBC and PCBC as the two main possibilities. This is the best detection analysis I have come up with so far.


The rule appears to look for a specific pattern of content bytes in traffic sent to port 3333/UDP.

The goal appears to be to detect an attempt to exploit a vulnerability in Wireshark, where parsing specific traffic causes a buffer overflow on the machine parsing the traffic.  The exploit-db link in the rule shows the details of the exploit for this issue.


Why does the SSL/TLS handshake have a client random?

For ciphersuites based on a key exchange and a signature as proof of possession, the sole way the server proves its identity is with the signature in the server key exchange message. This signature is tied to the TLS session because the signed data includes the client random and the server random. Apart from the client random, everything is chosen by the server, therefore the client random is the only thing that prevents anybody else from pretending to be the server after observing a single message from the server. A client trying to contact the legitimate server has no way to know that the server random isn't being repeated by an attacker. The client random is how the client challenges the putative server to prove that it is legitimate.

Even for ciphersuites where the client selects the pre-master secret and the server needs the private key to decrypt it, without a client random, two requests to the same server (with the same options) differ only because they have different server randoms. If I record a valid session then I can replay it to any client. I might not know what I'm sending, but I can at least feed obsolete information to clients that make identical requests.


Extract data from burp response and use in another request

Burp does not have a native functionality for that. You'll need to either write an Extension or use an existing one. I'd recommend Token Extractor.

Otherwise, you could also use Python for that. Proxy through localhost if you want to see the traffic in Burp. Do a regex parse (or json, if your data allows) and get the required token to use in the next request.


As Gumbo mentioned in his comment, it does not matter what you read in, but it does matter what you display after the fact. To simply answer your question, no. jQuery's .val() does not have any filtering that will protect you from XSS. You could perhaps take in the value into var toBeDisplayed and then perform your own filtering before it gets relayed to be displayed again.


Looking for a taxonomy of anonymization or re-identification properties

I don't know of formal work. Generally information is re-correlated from components by two heuristic activities: aggregation and inference. Aggregation is the collection of small components of a larger piece of information with the goal of collecting all the pieces. Inference is the collection of information fragments or related information with the goal of deducing or inducing the target information. Aggregation is frustrated by minimal size fragmentation and high dispersion. Inference is frustrated by noise, set mixing, and self-referential data.


If someone steals my laptop while I'm logged in, how can I protect my browser?

Isn't this true and ironic? We place so much emphasis on browser security and OS security -- and rightly so -- yet if I step away for a minute while my browser is open, ...

As I previously implied on another post quoting this comic, the problem is that fundamentally, if you leave your screen unlocked the OS has no way to tell that the person typing and clicking is not in fact you. It has already authenticated you, and for now it is just checking you are authorised.

"You" are completely authorised to change your facebook status to "I am a fool" inserting "your" choice expletives!

There is a solution to this - force the user to periodically re-authenticate. Unfortunately, to protect against the case of "I walked out the front door (away from my laptop) leaving it unlocked and open (did not lock screen)" you'd essentially need something that looked like UAC on LSD - "please re-enter your password to copy that file. And again to rename it. And again to open it" and so on.

However...

  and I come back and my computer is gone, basically all my online accounts are hosed.

That's not quite true. It really depends on the web account in question. For many accounts, whilst you do not need to re-authenticate to do some reputation damaging actions, there are some defenses:

Account sessions aren't maintained indefinitely, for this reason. After a certain amount of inactivity, accounts usually time out.
Changing sensitive account properties - like the password of the account or critical settings - can require re-authenticating.

  Or are there features to close a browsing session remotely -- including clear cookies -- in any of the major browsers, most of which I know can sync this data between devices?

I don't use browser syncing, but I suspect the answer is as always - vs a sophisticated enough attacker, this would not help.

However, there is again hope. Some web based services use API keys or equivalent to authenticate machines - so you can indeed invalidate for example your dropbox account on that system. Google Apps "Application Passwords" are another good example of this.

  which lock the browser itself after a certain amount of time or my computer goes to sleep/standby, where I have to authenticate to resume my session?

I'm not sure what use just locking the browser would be. To put this into context, the attack vector in this case is "someone who is not you, but fully authenticated as you". That's almost impossible to build defences against.

Indeed, the point of the comic, that "they could do everything but get to root" doesn't really apply to this attack vector. For starters, physical access probably will let you get to root one way or another, but more importantly those defences are to protect applications which are authenticated as you and have been compromised from further compromising the system in an automated fashion - this is particularly relevant when you are not the only user of the system.

There is a massive argument that in fact further isolation is needed at the desktop level between individual applications for a single user - e.g. between browser tabs as per the chromium sandbox, separate levels of Window that cannot interact e.g. UIPI, fully isolated applications via hypervisor e.g. Qubes. There are people building sandboxes on Linux e.g. 1 2 3. You can sandbox Windows further with say Sandboxie.

All of these neat little solutions to the malware-infects-your-browser-tab-but-is-isolated-from-your-bank-session cannot protect you from "yourself". The input device is still completely trusted once the "trusted" gui is unlocked.

The best defence you can really offer yourself has already been mentioned:

Lock your screen.
Encrypt your disk.

As has been noted, you are not fully safe against cold boot attacks, but I suspect a casual thief is not capable of implementing one successfully.


Why don't we use single input authentication?

When signing up for a service, you have a good chance of getting "This name is already in use, choose another" - or something to that effect.

In the system you propose, this would tell you that the access code is in use - great, open a new browser and log in with this access code! You've just hijacked somebody else's account.

You could find any number of existing access codes, just by trying to change your own.

Also, what if you forgot your access code? This can be mitigated if the system knows your e-mail address and can send you a new access code, but then you'd be close to a two-input authentication; you might as well use your e-mail to log in then.


Is it bad to put a certificate as CA in Firefox?

Yes you need to trust on that self-signed certificate Certificate because you have added it in your browser. But to create a new certificate signed by this CA you must have private key of the CA. So no body else can create certificate signed by your CA.


XSS via PDF when Content-Disposition: Inline?

Yes, there were problems in this area with Adobe acrobat reader plugin, just google for "adobe acrobat plugin javascript attack cookie".  I'm not sure if there are similar problems with the builtin JS viewers or if they are designed to live in a separate origin so that the same origin policy denies access. I don't think you even need to explicitly specifiy the Content-Disposition: inline.


How often is ASLR randomness refreshed, in Linux?

The Wikipedia page shows that the answer is "it depends". There are multiple implementations and patches around.

The important points to consider are the following:

A Linux executable consists in a main binary, and DLL (shared objets) loaded dynamically. In traditional Linux, the main binary is at a fixed address chosen at link time, while DLL are position-independent code.
DLL in Linux can be "moved around" inexpensively. Indeed, when a DLL is mapped into an address space, all references to elements of that DLL (from the DLL itself, and from other DLL and the main binary as well) must be adjusted to point to that DLL. This means that there MUST be some modification of some bytes in the main binary and some DLL, depending on how the address space is organized for that specific executable instance. The catch, though, is that any modified page (4 or 8 kB, depending on architecture), is no longer shareable (in physical RAM) with other instances for other executables concurrently executed. This tends to void the RAM usage advantage of DLL (historically, that was the reason for using DLL, but nowadays the ease of software upgrade is arguably a stronger reason).

In Linux (and other OS, in particular all those using ELF), the way out of this issue is to compile DLL "specially" as Position-Independent Code: in practice, the binary code thus arranges for grouping all (or most) references which must be adjusted into the same pages, using an indirection table (the "GOT", aka "Global Offsets Table") which is dynamically located by its position relative to the invoking code. This means that most DLL pages will remain unaltered when the DLL is loaded, and thus will be shared with any other instance of that same DLL in the address space of another executable.

This contrasts with the way things are done in Windows, where the OS tries to load the same DLL at the same address for all process which use it, so that the references may be modified "in place" and still be shared, because all the process will see the same DLL at the same address. (More than 20 years ago, at the times of "libc4", DLL were not "moveable" in Linux and were always loaded at a fixed emplacement, for all process.)
The main binary is supposed to be linked at a fixed address; however, a mechanism similar to PIC DLL has been also implemented for main binaries: it is called PIE. I explained it at length there. Since PIE can break some non-C applications, Linux distributions which use it tend to reserve it to some applications which are deemed "vulnerable" (i.e. applications which have some network activity).
Linux also features VDSO, which can be thought of as a DLL provided by the kernel, instead of being mapped from a file. The kernel's support for ASLR will randomize the VDSO address on a per-process basis.
Any randomization requires space, and thus may imply address space fragmentation issues (allocation of big blocks may fail because the free space is split into several smaller holes). This is especially true for 32-bit Linux variants; on 64-bit architectures, the address space is still sufficiently big (compared to physical RAM size) to avoid problems. Therefore, ASLR may have to be disabled for some applications, e.g. photo/video editing. This can be done on a per-process basis with setarch.

From these, we get the following:

When ASLR is applied in Linux, it usually is applied on a per-process basis. If you start the same process twice, then the DLL will be loaded at distinct addresses (and the main binary too, if it was compiled for PIE). This is easily witnessed by running the executable within gdb, and, indeed, when you are tracking bugs, the first thing you do is to disable ASLR.
Prelink, if applied, prevents ASLR (at least for DLL and binary; heap and stack positions may still be randomized). Prelink may counterbalance this by doing randomization itself, but, by construction, this will be fixed for each executable: a pre-linked executable will find its binary and DLL at the same places, always; however, other pre-linked executables on the same machine will see the same DLL at different addresses, and this is machine-specific, so other machines will obtain address spaces laid out differently. It is also recommended to do a new prelink regularly (e.g. on a weekly basis), which rerandomizes things (and you will get it for evey DLL upgrade, too).
Stack and heap are also randomized. The initial stack position, as well as the starting point for the heap (for brk() system calls), are chosen by the kernel upon process start, and each execution puts them at a new place (if ASLR is enabled). Also, the memory allocator may rely on mmap() (it will typically do so for large blocks), which is randomized, and this extends to thread stacks, which are dynamically allocated. By default, glibc will use mmap() calls for any block of more than 128 kB, and stacks for new threads default to 1 MB.
When a process is forked, the child necessarily obtains the same layout as its parent. However, DLL loaded after the fork may end up at distinct addresses.

Since all of these depend on the kernel version and patches, and configurable options, the answers to your question are thus necessarily distribution-dependent. For instance, you may see how things go in Ubuntu there (basically: ASLR everywhere, PIE for only a specific list of packages, no prelink). The only common point is that ASLR on Linux is never boot-dependent: when randomization is not applied for each process instance, then this is due to prelinking, which is permanent across reboots (but should be re-applied on a regular schedule).


Possible attack vectors for a web site scraper

What you're describing is a sort of proxy that returns basic information from an external website. I don't think it's a weird question at all, and I know of a couple of attack scenarios.

Your design practially allows SSRF (Server-Side Request Forgery) by design. This doesn't have to be a big deal, but can have serious consequences. For example, if you run your application in AWS, one can call the AWS meta-data endpoint, which in some cases can grant an attacker temporary access keys to parts of your AWS environment.

SSRF can also be used to access your internal network, the server's loopback interface, and other endpoints that your server is whitelisted for. You've got to make sure to blacklist internal addresses (I would resolve the domain and parse the IP address to match certain ranges). And you've got to block the AWS meta-data endpoint when using AWS.

Can users enter a full URL? Ensure that they can't use different schemas, like file:// or smb://, or they might read local files from your server. Also, note that if you return the URL on your website, they might use a javascript:-schema to perform XSS when the URL is clicked.

Are you using an XML parser to parse the external HTML? If so, make sure you're not vulnerable to XXE and secure your XML parser by not allowing External Entities.

Needless to say I hope you don't append your user's input into some system command, like curl -s [URL], since that would allow for Command Injection. It's so stupid that I don't like to mention it, but I've seen people do it.

Note that showing data from the external website in JavaScript-context or in HTML attributes requires different encoding than HTML encoding.

The rest depends on your application's architecture. Are you storing the data in a database? If so, make sure you're not vulnerable to SQL-Injection, etc. Good luck!


How can I prevent someone from carrying out a file from a machine

Well, you're going to have to fix your boss's "trust issues."  I know of a defense contractor that removes optical drives and fills USB ports with a glue gun.  Classified information is on an isolated network with no outside access.  But, the real thing they do is address the "trust issues."  Their employees who work with classified data must have security clearances.  Even that isn't perfect, but it has apparently worked for them so far.

If I can see a file, and I'm sufficiently motivated, I can make a copy with a pencil or even commit parts of it to memory.  (Edit: I wrote this before seeing your comment on the value of a transcription.)

What you are looking for is something called "originator controlled access control," ORCON, and as far as I know it doesn't exist except in contrived proof-of-concept situations.

The best you can do is reduce the possibilities.  How far you reduce the possibilities, and how much you spend doing it, are business decisions.  The boss needs to assign a value to protecting the file: "How much would you pay an insurance company every year to cover the file against copying?"  That's your budget, and you can then tell the boss what you can do within that budget, which is far better than saying you can't do anything.  You can't absolutely protect the company vehicles from automobile accidents, either, but you can reduce the possibilities through careful maintenance, driving record checks on new hires, driver training, etc.  How much you can reduce the risk depends on how much you're willing to spend.

You, and maybe your boss, should read Ken Thompson's Turing award lecture, “Reflections on Trusting Trust”.


Suspicious entries in MySQL database from user input forms - sql injection?

You might have been subjected to the process called "Fuzzing". This is when an attacker submits many inputs and perceives how your web application behaves. Web Fuzzing could include sql injection, XSS, overladed input or invalid input strings in general.

Well first you need to look at the entries..
Do they contain SQL commands?
like SELECT, UPDATE, DELETE, INSERT
or sql operators, such as  OR + -
or many sql characters such as ' > < = "

If u see them, then it means that the hacker tried an SQL injection on your database.

If you see any html characters in your database, the attacker tried to execute stored XSS against you.

If the inputs are long, the attacker tried perhaps to DOS your website and bring it down.
(Same is true if he submitted a lot of input in short time).

You need to observe the functionality of your site which accepted those values. If the entries/inputs didnt come from a specific functionality (e.g. registration form) than it was probably a hacking attempt.

Other types of injections that exit are LDAP, XML, Command and a few more that i cant remember. Look for characters that contain the following: % , > , ( , ) , ", ', dots , commas.

You can test it with mysql commands/operators:
1) LIKE '%searchStringGoesHere%'
2) MATCH AGAINST.

Panels like phpmyadmin, provides the same functionality but for people who dont know the sql language.

Alternatively, someone might have run some SEO bot on your site, and that was a spam attack, which is not much to do with security, but you could introduce captcha on your forms and tokens per each request to prevent a XSRF attack


OWASP CRS Anamoly scoring,, ModSecurity WAF

I try give the answers for your question instead of comment :).
Q1: TX:PARANOIA_LEVEL "@ge 1" means about if TX:PARANOIA_LEVEL >= 1, and all four PL will match. Please read the reason above the rule.
Q2: yes, the += is same as you wrote there.
And how this logically applicable if my request is being validated by multiple rules? - the rules evaluated one-by-one, as you (or the rule maker) listed them (grouped by phases). If a rule contains a value giving action like above, then just evaluated - but the TX (or tx) means transaction, so for every request has an own TX collection.
Q3: I think the best start point would be this. It's a bit outdated, but the basics are there. A quick summary: every rule has a severity level, which could be one of the notice (with points 2), warning (3), error (4), critical (5) (these are defined in this file. Every rule activated on different PL (paranoia level), so the chosen score (variable) will incremented by the severity value.


Can malware on my computer infect my phone?

There is no reason why malware cannot spread from any kind of device to any kind of device, it all depends on how the malware has been developed. AFAIK there is no malware known that infects both PCs and mobiles at this point, but there's no reason it can't be done. Possible vectors are:

infected music files: a malware infected music file could be spread to a mobile during some sort of sync, like an itunes sync
Over the network: mobiles are often connected to wireless networks, malware could be designed to use vulnerabilities in mobile OSs to infect them
Over a USB connection: when you connect your mobile to your computer communication is possible between the 2 devices, and communications path is a possible malware infection vector
Bluetooth

Of course there are other ways a mobile could be infected (phishing, infected emails, etc), but they are not a direct spread from a computer to a mobile.


How to prevent your WiFi from getting hacked by Kali Linux?

WPS stands for WiFi Protected Setup. It is a configuration protocol aimed to ease the configuration of (adding) new devices.

WPS is not required for WiFi network to work and the configuration that it automates can be performed manually.

As a non-essential protocol, the easiest and most reliable method of protecting against exploiting it, is disabling the WPS altogether.

The weakness in WPS mechanism is an ease of performing a brute-force attacks.

Implementations of WPS differ among devices and some vendors offer additional measures to impede the attack attempts, so it doesn't mean that a WPS-enabled device is inherently insecure.

The attacks on the other hand take advantage of insecure default settings or firmware bugs in some devices and there is no solution to the problem other than user awareness.


Is it possible to export an expired GPG subkey's public key without signatures?

While not explicitly stated, apparently --export-minimal drops expired subkeys, which make sense.
The option you need is probably self-sigs-only. However, that is a filter only for import. We would need to use an intermediate keyring for that
TEMPORARY_KEYRING=`mktemp -d --tmpdir`
gpg --armor --export keyid | GNUPGHOME="$TEMPORARY_KEYRING" gpg --import --import-options self-sigs-only

# We can check it imported what you wanted with
GNUPGHOME="$TEMPORARY_KEYRING" gpg --list-keys --list-options show-unusable-subkeys

# Then you simply export it
GNUPGHOME="$TEMPORARY_KEYRING" gpg --armor --export

Other options include:

Faking the current time:

faketime 'time-when-subkey-was-valid' gpg --armor --export --export-options export-minimal subkeyid

Manually fetching the required pieces

gpg --export keyid | gpgsplit

# Manually inspect the created files and remove all the .sig not from your own master key
# Generate the new key file with just the bits you want
cat 00* > mykey.gpg


Scripting a search through php files for dangerous calls for manual review

Definitely this list is not enough. First of all, it is not complete, secondly, different obfuscation methods can be used to hide web-shells, other malicious scripts.

For such purposes long time ago I have written my own PHP-script to look for dangerous places: http://0x416d73.name/proj/fcc.html. It is written on PHP, so don't expect it to be as fast as "find" command. Though, it allows to check file hashes, view which files have appeared, are missing or has changed. I advise you to test it first against some small script, just to feel how it works, before running on production server.
Also, specifically for search for vulnerabilities in PHP code, some time ago I have put together some easy bash script - http://privatepaste.com/88a5d5eaa3. It is not complete, might require tuning and criticism from bash guru's :)

If you want to continue on your own script, here is nice list from which you can extract what you need: http://privatepaste.com/dc335ccb86.

Updated: as it figured out, topic is about code review. Above mentioned solutions still makes sense, but then I would like to mention this one project: http://sourceforge.net/projects/rips-scanner/. To my mind, currently it is the best freely available source code analyzer for PHP web applications.


How to identify malicious Wordpress user agents

Your method is sufficient to deter most automated scanning attempts of this nature
They are most likely probing for weak plugins.

Your best bet is to minimize the use of plugins, and keep everything up-to-date automatically.


What questions should be asked when joining a new security team?

What are the strengths of each team member that I will work with regularly? (i.e. programming, linux, networking, regulations, etc.)
Where is our documentation? You hopefully have a wiki, a knowledge base, or set of documents somewhere that explain your processes and policies. If you don't, be a hero and get started on one.
What are the current projects the Security team is working on? This is pretty self-explanatory, get up to speed on the team's roadmap and figure out how you can best help.
What is my career path here and how is my performance rated? Not security related, but always important to know at any job.
What is your change control process (if any)? This one is super important and if you don't have one you'll want to push for one eventually.
Which technical team does what and what is the process to engage them? This is important since you'll want to quickly identify who can answer your questions about specific topics and who to talk to about specific issues. Different teams may have different engagement styles and it's important to follow their process.
Who are our allies in the company? This is pretty self-explanatory. Which employees or teams "care about security". It's nice to identify which groups are less likely to resist reasonable security requests or even be champions for security improvements.
What is the team's philosophy? This is important because you want to be sure that you're approaching situations the same way as the rest of the team. You want a one voice approach as best you can externally. Keep the snarkiness internal. ;)
How far can I push our users? I generally find the "advisory approach" where you seldom really push works better, but some organizations view security as paramount and want security to be aggressive in their stance.
How does the business operate? This involves understanding the org chart, understanding the company's strategy, business risks, etc. Without knowing this you don't have the context to give them the best security answers you can. I find a lot of people don't focus on this to their detriment, but it's really important.


How do certificate issuers become trusted?

Is it impossible for one to start his or her own root CA without the consent of computer manaufacturers?

Everybody can create it's own CA and install it on all computers s(he) has control to. It is not unusual for larger companies to have their own internal CA.

  Also, what is stopping an attacker from simply installing "trusted" certificates in people's computers?

Existing security measures should in theory make it impossible for an attacker to install additional certificates on machines owner by others. But if the attacker manages to get access to the machine (malware, physical access, deal with the vendor...) adding another trusted CA is possible. This is actually done in practice, see Superfish.

Apart from attacks new trusted root CA gets typically added in companies to support their own infrastructure or to make analysis of SSL traffic in firewalls possible (SSL interception). For SSL analysis also several personal antivirus solution install such new root certificates.


Does routing internet traffic via VPN through a company proxy gain any more security?

Does the additional proxy server for internet access provide more security than it (potentially) costs in effort ?

If the proxy is just a dumb proxy then there is no additional protection. But usually the company proxy is actually a system which analyzes the traffic for malware or data leakage, blocks potentially malicious sites and might even do HTTPS interception to analyze encrypted traffic. In this case the proxy offers more protection than direct unfiltered internet access from the Laptop.

  ... If the laptop is compromised (backdoor running)....

That's not the main point of the proxy. The proxy is there to make infections harder in the first place. And it might also be used to detect and block typical C&C communication done by malware.

  ...  if the user has root access and can change network configuration ...

If the user is granted full access to the configuration of the system there is nothing technical the company can do to stop the user from deliberately violating the company policy of using the proxy. But the company can easily check who uses the proxy by looking at the proxies logs and charge users who don't use the proxy with violating the policy.


Is it safe to call mount(2) and pass the password as a parameter?

mount(2) might be implemented by calling a process it is just the opposite: mount(1) is a front end ultimately calling mount(2) which being a system call asks the kernel to do the job
mount(2) might have its parameters in non-mlock()ed memory unsure of it, but why do you think that mlock memory is secure? AFAIK root can read /dev/mem and /dev/kmem as (more?) easily as the content of the swap partition...
mount(2) might (maybe depending on the file system type) print error or log messages exposing its parameters it would indeed be a security threat, and I do not know any network mount utility ever logging a password in clear text. Anyway as said in 1, any attempt to mount the network share will ultimately end in a mount(2) call so you cannot avoid it.

TL/DR: it is far more secure to call mount(2) that starting a subprocess to call mount(1) because the parameters passed to the subprocess command will be accessible through the process table and can be displayed with ps with the appropriate options and the error condition processing will be much simpler.


Is it possible to easily retrieve Thunderbird's passwords with access to HDD?

On linux, the password database is stored in:

/home/$USER/.thunderbird/$RANDOM_STRING.default/signons.sqlite

See @Karrax's answer for Windows locations.

You can examine this file interactively using the sqlite3 CLI:

sqlite3 ~/.thunderbird/zxcv1357.default/signons.sqlite

sqlite> .tables
moz_disabledHosts  moz_logins
sqlite> .schema moz_logins
CREATE TABLE moz_logins (id                 INTEGER PRIMARY KEY,hostname           TEXT NOT NULL,httpRealm          TEXT,formSubmitURL      TEXT,usernameField      TEXT NOT NULL,passwordField      TEXT NOT NULL,encryptedUsername  TEXT NOT NULL,encryptedPassword  TEXT NOT NULL,guid               TEXT,encType            INTEGER, timeCreated INTEGER, timeLastUsed INTEGER, timePasswordChanged INTEGER, timesUsed INTEGER);
CREATE INDEX moz_logins_encType_index ON moz_logins(encType);
CREATE INDEX moz_logins_guid_index ON moz_logins(guid);
CREATE INDEX moz_logins_hostname_formSubmitURL_index ON moz_logins(hostname, formSubmitURL);
CREATE INDEX moz_logins_hostname_httpRealm_index ON moz_logins(hostname, httpRealm);
CREATE INDEX moz_logins_hostname_index ON moz_logins(hostname);
sqlite> select * from moz_logins;
3|imap://imap.example.com|imap://imap.example.com||||MEIEEPgAAAAAAAAAAAAAAAAAAAEwFAYIQwErTyUiOp12345GmuM2KNXcZ=|MEIEEPgAAAAAAAAAAAAAAAAAAAEwFAYIQwErTyUiOp12345GmuM2KNXcZ=|{1234abcd-beef-feed-face-0a0a0a0a0a}|1|1320123123123|1320123123123|1320123123123|1
4|smtp://smtp.example.com|smtp://smtp.example.com||||MEIEEPgAAAAAAAAAAAAAAAAAAAEwFAYIQwErTyUiOp12345GmuM2KNXcZ=|MEIEEPgAAAAAAAAAAAAAAAAAAAEwFAYIQwErTyUiOp12345GmuM2KNXcZ=|{1decafbad-fa11-1234-1234-abcdef0123456}|1|1320123123123|1320123123123|1320123123123|1

If you wanted to fetch usernames/passwords from code, it's as simple as:

echo "select encryptedUsername, encryptedPassword from moz_logins;" | sqlite3 ~/.thunderbird/*.default/signons.sqlite

or the equivalent in your favorite programming language with sqlite3 bindings.

Of course, if they're encrypted (as shown above) you'll need to put some effort into guessing the master password used for encryption. As a user, know that if you use a weak master password (e.g. P4ssw0rd1) it will be trivial to get the cleartext passwords.


A Honeypot will not control connections, so if that is what you want then you are not looking at the right technology.

Honeypots emulate real systems, so unless you actively prevent it, it will be able to attack other systems, exactly as if it was a real system.

This site has other questions in setting up honeypots, so just have a read of them.


How Secure to is to forward CCTV stream to device's cloud

How secure is this in terms of privacy ?

One can only guess: If the data are not encrypted for transport they can be easily sniffed. If the data are encrypted for transport but not at rest a hack at the cloud storage might make them available for others. If they are encrypted for rest but the provider of the cloud storage has the key they can access these. If they are encrypted on the origin device and a key is only shared with the viewing device it might be safe.

Note that in all these examples encryption means proper encryption and not some self-made algorithm or messed up implementation of well-known algorithm or weak algorithm which is often done by less experienced developers and/or because of hardware constraints on the device. The same is true for key sharing.

Apart from these a passive listener might notice when and how many data are transferred and thus make assumptions about the activity (some CCTV send only when they notice activity). And depending on the system it might be possible to block transmission of data without notice to the viewer or even replace it with different data.

  How can we stream this video into our own cloud environment and view from the mobile? Can we set up our own cloud back up as well ?

That's a product specific question you have to ask the vendor.


I would strongly recommend these OWASP materials:

Application Security Verification Project at https://www.owasp.org/index.php/Category:OWASP_Application_Security_Verification_Standard_Project

Development Guide at https://www.owasp.org/index.php/Guide_Table_of_Contents

Testing Guide at https://www.owasp.org/index.php/OWASP_Testing_Guide_v3_Table_of_Contents

and Code Review Guide at https://www.owasp.org/index.php/OWASP_Code_Review_Guide_Table_of_Contents


Why would you want to run DNS servers externally?

When talking about DNS servers, it is important to distinguish between recursive resolvers (those servers providing clients with name resolution services) and authoritative nameservers (those servers answering final queries from local zone files).

If you are talking about recursive resolvers (DNS caching servers), then, by all means, if an organization has an intranet, the recursive resolvers should be there, not on the Internet. And if the organization does not have a segregated Intranet or internal network, recursive resolvers that permit queries from a restricted set of sources are certainly a good idea. As you say, an ISP might have a case for a wide open resolver, partly because queries for non-public names aren't expected to be handled by such a server, partly because of the trouble of listing very large amounts of permitted IP addresses, and partly for historical reasons (it's the way it was always done in the past).

If you are talking about authoritative nameservers, then one good reason to have those servers out on the Internet is for excellent response time. Every single client who wants to reach your website, your email server, your SIP server, or pretty much anything else you can think of to offer by name under your domain name is sooner or later going to generate a query against your authoritative nameserver (except if the answer has already been cached). The response time of this server is going to impact the response time of every service you offer. You want that query to go to a responsive server in a well-connected hosting centre, if possible. If you don't have servers of your own in such places, outsourcing authoritative nameservice to a DNS provider is probably a good idea. These days, almost every domain registrar also offers outsourced authoritative nameservice if you want it. I exaggerate a little bit the importance of a very responsive authoritative nameserver, but you get the message.

Still on the topic of authoritative nameservers, I should note that at least one of the threats you mention, cache poisoning, is not applicable: an authoritative nameserver is configure to not answer queries from cache. As for amplification attacks (where spoofed packets are sent with a question, the answer is larger than the question, and this answer gets directed at a victim), the location of the nameserver (behind a firewall or not) isn't going to make a difference. To some extent the nameserver has to answer those queries no matter what or else client's aren't going to find the services under your domain.

A common configuration for organizations with intranets is split DNS: there are two sets of authoritative DNS servers. One set has the public version of the zone, and it belongs out on the Internet. The other set has the internal version (which probably has a superset of the contents of the public version) and belongs on the intranet. This case is pretty simple. The public authoritative servers are unable to accidentally leak any private DNS information because they don't have a copy of the internal zone file and they can't get one since they are out on the Internet. (Obviously this assumes your zone file deployment process won't ship an unsanitized zone file out to the public version of the server during an update!)


How do I back up YubiKey-backed TOTP authentication?

When setting up TOTP with a site, they give you a shared secret.

Yubico Authenticator uses your Yubikey to store that info.  As long as your key is present, all instances of Yubico Authenticator are interchangeable.
Most sites will only share a single secret with you, but you can freely update that secret.  When registering a "new authenticator" with a site, you can put that secret on multiple keys/authenticators before telling the site you're done.


What security standards and regulations are in place for bank ATM?

MasterCard and VISA enforce very strict regulations on any system which operates in any way in the vicinity of their precious credit cards. If a bank or an ATM operator lets the communication be tapped, then the VISA thugs will skin them alive, trample their organs, then expose their dismembered bodies on the Wall Street Bull, as a warning for other banks. Their fierceness is much higher than what any public administration could ever hope to achieve; because this is about important stuff (money). This is private business, with contracts; the legislator did not meddle with this beyond asserting that customers are not ultimately responsible unless proven otherwise (thus forcing banks to take their responsibilities).


Will Bitlocker drive encryption restart if my laptop runs out of power?

Bitlocker encryption can be interrupted when the power is off, it will resume from where it left off; the next time you boot up the machine.


Do I need to disable TLS 1.0 altogether?

Before you disable this get an audit of browsers connecting to your site. You need to cross reference this with TLS 1.0 support. This will give you an idea of your customer base that requires this as if they can't support anything over TLS 1.0 you will be cutting them off.

As for do you need to cut it off, what does your app do?
What regulations does your industry follow?


Are you sure that changing your 300 passwords is out of the question? Would you rather open 300 support-tickets to reclaim your accounts?

You should think about setting up a password-database like KeePass2 or simmilar in the process of changing you passwords, this will help you setting different passwords for each account.

The threat seems to be the person or group that got access to your plaintext password. If you got no idea how this could happen, you should not consider your system clean and do a reinstallation of all your boxes.


The short answer is : no. That is not what I said, nor what I implied.

Using the tradeoff that I identified and talked about, you can trade memory for CPU time. So yes, you can reduce a particular derivation from 16MiB to 8KiB (approximately). However doing so will require several orders of magnitude more logic to be executed by the CPU. Some efficiency is gained by cache locality, but in general, it should be much slower. (on average, about 8,000 times slower than the 16MiB version, but as much as 16,000 times slower, depending on the exact random distributions of the algorithm).

There is a more interesting alternative though. My attack was an all-or-nothing bais. Basically, completely eliminate the V array, at the cost of increasing complexity. But you can make a more nuanced tradeoff. You can cut the array in half, and re-compute every-other value. Or cut it to every third value. Trading off storage space for CPU space. But at a varied degree. This is commonly referred to as a TMTO defeater (Time-Memory-TradeOff Defeater).

I did a more thorough analysis, including a proposed fix on this thread. It's worth noting that at least one of the proposals for the Password Hashing Competition uses my augmented algorithm.

So no, scrypt is still incredibly strong. And for its primary use case (as a KDF), it's quite a bit better than the alternatives.,

The point I was trying to make with my post, is that when not tuned optimally (used with improper settings) or with very fast settings, it can be significantly weaker than existing algorithms. Specifically for password storage. Where you know the result, and are looking for the source material (password).


Theory

Maybe - and this is a fat maybe - someone is trying to desensitize you to clicking on opt-out links so that you get trained to click through any link you get for protecting your privacy.

What do you do?

Nothing. If you didn't request the email, then don't click it.

What's the threat of clicking on a link? (and how do you protect yourself)

someone could try to exploit vulnerabilities.

patch your browser
turn off javascript
don't click on unknown links

You could fill out a form and give away information

don't do that.
Type in the url for the site you want to login to.
check the certificate, etc.

If you didn't request the email, then don't click it.


Does the server administrator see what sites I visit

With TOR, the communication between you and the TOR network is encrypted. Unless the TOR exit node also happens to be on the same network, your administrator will only get encrypted traffic.

Incognito mode on web browsers does not affect the network encryption at all. Its effects are localized to your own machine (what site visits are logged in the local history, what form input is saved for auto-complete, what cookie database is used, etc.). An eavesdropping network administrator is not impeded by this.

The actual use-case for incognito mode is when you share the same computer with multiple users and don't want them to know what you did. It's not supposed to protect your anonymity on the network level.


How to present our browser's public certificates (self signed)?

make a connection with www.google.com, how will it provide a public certificate(self signed) to my browser?

You seem to be confused about how SSL/TLS works.

Google is maybe a bad example to choose - its a certificate authority who can issue certificates recognized by most browsers. So all its certificates are self-signed.

If you have created a client certificate, that has no impact on how google's service presents its certificates.

Your client certificate only has some relevance when you connect to a service which expects to see a client certificate. While widely used within and between organizations, I'm not aware of any public services using private certificates.

Unless you have some sort of relationship with the service provider and their service is specifically configured to handle client certificates, your certificate will be ignored.

As to the case where a provider has said that they expect, and can handle client certificates, it would be very unusual (i.e. incompetent) for them to invest any trust in a self-signed certificate unless

you have made some provision to provide them with the public key of the certificate or the signing certificate via a secure channel,
OR there a subsequent enrollment (e.g. making a payment) using the connection secured by the client certificate which then forms the basis of the trust


Can an employer see what I'm doing on my iPhone whilst logged onto wifi

According to Whatsapp, all message traffic between the server and your phone are encrypted. The same applies for iMessage. The initial contact for iMessage is initiated via normal SMS, and does not travel through the wifi network.

Therefore, it will not be possible (barring homebrew crypto security flaws) for your employer to read messages that pass through its wifi network, he will only be able to see that you are using those applications.


Downloading software from websites that lacks a padlock

The padlock is just a visual cue used by the browser to show you that your traffic is being encrypted when sent and received from the server. It represents an SSL Certificate but for this answer we can just use the term padlock.

The padlock does not make any claims of trustworthiness, it merely shows whether the traffic between your computer and the server is encrypted, that is it cannot be seen (in clear text) by other people sniffing traffic between the two endpoints).

In fact, many times attackers will purchase SSL certificates (the padlock) to encrypt traffic to evade Intrusion Detection Systems (IDS) and Intrusion Prevention Systems (IPS), so seeing the padlock should not automatically equal safe content.

Recommendation

Instead or relying on the padlock, use reputation based content filtering and pay attention to the domain used in the URI to avoid social engineering / phishing scams directing you to unscrupulous content.

Examples:

paypal.com != paypa1.com
google.com != g00gle.com

UPDATE

As noted in the comments below, there are Man in the Middle (MitM) attacks that can fool a victim into thinking they are connecting to a legitimate source (DNS cache poisoning), as well as subtleties in language character sets (IDN homograph attacks) that can look like the English (Latin) Character set.
Credit: @iismathwizard


Does the CA create the public key or is it created by the requesting server and sent to the CA?

The former is correct, as verified by RFC 2986: PKCS #10: Certification Request Syntax Specification:
The process by which a certification request is constructed involves
   the following steps:

        1. A CertificationRequestInfo value containing a subject
           distinguished name, a subject public key, and optionally a
           set of attributes is constructed by an entity requesting
           certification.

        2. The CertificationRequestInfo value is signed with the subject
           entity's private key.  (See Section 4.2.)

        3. The CertificationRequestInfo value, a signature algorithm
           identifier, and the entity's signature are collected together
           into a CertificationRequest value, defined below.

Paraphrasing: the public key of the subject (the requester of a certificate) is included verbatim in the CSR. It is not "computed" by the CA, but it is used to verify the signature of the CSR (to ensure that it was indeed requested by the holder of the key pair and not tampered with).
As for the DigiCert article: it goes on to state:

the SSL certificate itself is sometimes referred to as "the public
key."

This would explain their use of "public key" instead of "certificate". As you noticed, this only brings confusion to an article supposed to explain the use of key pairs.


Public key in resources for avoiding man in the middle attack

What you are asking is basically redefining the "common SSL". However, you are basing trust on the server only, whereas in SSL the trust is delegated to a third party. Moreover, in SSL certificates are signed, therefore you can verify their authenticity.

So yes, the scenario will be able to prevent MitM attack (in a way), but the user loses some trust in the process (compared to SSL) because:

there is no more verification of the key
there is no one to vouch for your identity as a certification authority would do

A scenario that could be devised to perform MitM would be someone tampering with the APK to change the public key to replace it with another he has control on. This is probably not technically easy but not impossible either.

Finally, you would be better using a recent version of the SSL/TLS suite rather than developing your own protocol.


What's the risk from enabling ptrace in docker?

There's some good detail on this topic, in this whitepaper.

Essentially the problem is that allowing ptrace will allow the contained process to bypass any seccomp filter in place, allowing dangerous syscalls to be made.  To quote the document

CAP_SYS_PTRACE: The ability to useptrace(2)and recently introduced cross memory
attach syscalls such as process_vm_readv(2)andprocess_vm_writev(2).

If this capability is granted and the ptrace(2) syscall itself is not blocked by a seccomp
filter(as discussed more in Section 8.3 on page74),
this will allow an attacker to bypass other seccomp restrictions.

Update - As mentioned below in comments from @forest the above only applies to versions of the kernel before 4.8, so modern Linuxes (possibly excepting RHEL/CENTOS 7 and earlier which are still around) shouldn't have this problem.


How man in the middle attack works on multiple targets?

If due to ARP spoofing the gateway the clients send all traffic to the man in the middle, the MITM then forwards this traffic to the original gateway with its own MAC and IP as sender. This means that the responses to the traffic are send from the gateway to the MAC and IP of the MITM which then rewrites the response and forwards it to the original client. Thus there is no need to spoof the originals clients MAC at the gateway.


Broadcast encryption protocol for file sharing service (a-la Dropbox)

First let me say that this is essentially a restatement of the answer linked in your question.

I suggest that you use symmetric key encryption to guard files and asymmetric (public) key encryption to guard the symmetric encryption keys.  You could use an existing PGP/GPG key pair, or, to make this transparent, generate a key pair explicitly for your application.  If you do the latter, please use tried and tested code to generate the keys.

You stated a requirement that no keys be stored on the server because " I don't want to give the service's maintainer the ability to access user's data."  As long as keys stored on the server are encrypted, the service's maintainer has no access to the data, so I've interpreted "no keys on the server" as "no keys which would allow access to the data."

The process works like this:  When a file is uploaded, it must be encrypted (by an app on the sender's client) using a symmetric algorithm like AES and a randomly-generated key.  The key must be generated by a cryptographically secure random number generator (CSPRNG)

The encrypted file is uploaded to the server.  The symmetric key, encrypted with the sender's public key is uploaded as file metadata, associated with the sender's ID.  If a file is uploaded by a user with the ID alice@example.com, the metadata would look like:

alice@example.com | encrypted (with KA) symmetric key

At this point, only Alice can read the file because only Alice has the private key that will decrypt the  file's encrypted symmetric key.  (The application must have discarded the unencrypted copy of the symmetric key soon after the metadata were updated.)

If Alice wants to allow bill@elsewhere.com to retrieve the file, she adds to the metadata a line like this:

bill@elsewhere.com | encrypted (with KB) symmetric key

Alice does that by retrieving her own metadata, decrypting the symmetric key with her private key, and re-encrypting with Bill's public key.

Assuming the metadata file itself is unprotected, Bill can pass access to Charlie by performing the same kind of operation.  That is not only OK, it is good.  Bill can obviously download the file and give a copy to whomever he pleases.  If access is passed through the file's metadata, then there's a record of what happened.  (Bill can still pass the file to others, but is no longer forced to take that route.)

Because of your requirement that only one password be used, you'll need to use the password that unlocks the private key as a login password.  One way to do that might be to store on the server an authenticator for each user, encrypted with the user's public key.  Only a user with the corresponding private key can decrypt it and return the plain-text authenticator to the server.

Everything up to the login involves end-to-end encryption, and so everything passing "over the wire" is encrypted.  For the login authentication, the client must return the plain text authenticator, and that means a TLS connection is needed.


Can an attacker steal information from my HTTPS page by embedding it?

First of all, it doesn't matter if you are using https or http. TLS only protects your data during transmission. The browser certainly must be able to read the data even if it is in some iframe, therefore whether you are using https or not is irrelevant.

Browsers are protecting your data via Cross window communication policy about which you can read here: https://javascript.info/cross-window-communication or at wikipedia: https://en.wikipedia.org/wiki/Same-origin_policy

In sort, you can't access the iframe data from the parent, unless it is from the same "origin" (exact same domain).

In fact, this protection may cause some problems for which the CORS mechanism was invented: https://en.wikipedia.org/wiki/Cross-origin_resource_sharing


These days it doesn't actually make a huge difference. Or rather, it depends very strongly on your backup plan, disaster recovery plan, your RPO and RTO and the scenarios you expect to want to recover from.

In any modern environment; you're likely to also have some sort of SAN. Your backup solution should interact with the SAN, but not the rest of the network; this allows you to back up data without exposing your backup solution to risks associated with the hosts you're backing up (this is a generalisation).

The decision between disk and tape should come down to your environment and your requirements. If you need to store your data for a long time: tape, properly handled can last decades, so as long as you test their integrity every ~10 years, you should be pretty safe. It is cheaper per GB (in the order of something like 90%), and the principles behind storage and retrieval are well understood. It is however, very, very slow compared to disks.

Disk can potentially be always available, it is a lot faster and lends itself to replication via WAN/etc. - but you generally have to leave them on and running to verify their integrity, and buying more disks can be a limiting factor if you're keeping your data for a good amount of time (how many fit in your array?).

In most environments, you have a combination of disk and tape; certainly for environments with any sort of compliance overhead. Disk backups deal with replication and hot site DR, tape deals with historic backups and long term storage.

To answer the question:

  Is physical tape backup better than disk to ensure integrity?

It depends on how long you're storing, your backup cycle, and what you're backing up for (will you need the data in a hurry?).

  So what do you think about tape vs disc? Particulary in financial institutions.

I think any serious environment will likely have both. Particularly financial institutions that require high availability and minimum downtime - if their server room floods, you'd expect them to be up at Site B very quickly (so, from disk), and if they need to dig up accounts from 30 years ago, I'd expect them to be able to by going to their tape library.


The protection is called "luck". The probability that such an event occurs are sufficiently low that it can be neglected. Provided that the RSA keys are generated properly.

In 2012, some researchers made an interesting study in which they collected 11.5 millions of publicly available RSA keys (e.g. keys from SSL server certificates). They found that some keys were widely duplicated (my own sampling found the same: apparently there are widely deployed ADSL or cable modems that host a SSL server, all with the same public/private key pair). They also found, and that's what corresponds to your question, that factor sharing between distinct RSA keys was rare but not unheard of. This demonstrates use of a poorly seeded PRNG.

Indeed, any practical RSA key pair generation will produce random primes by running a PRNG seeded with some "initial randomness". If that initial random seed has not enough entropy, then the number of possible primes that this generator may produce is low. For instance, if the seed has 40 bits of entropy, then it suffices to generate a million RSA keys or so to obtain a collision (two of these keys using a common prime factor). More generally, if the seed has entropy n bits, then everybody should be safe as long as less than 2n/2 RSA keys are generated. Proper PRNG will aim at n = 128 or more.

While there is no need to fear such an outcome with properly generated RSA keys, this fact illustrates that adequate PRNG seeding is not easy, and, crucially, it is very hard to ascertain whether a given seeding process is adequate or not. Some embedded systems, and virtual machines, are most at risk of not having enough "physical" entropy to work with.


iOS 12 built in password manager vs third party apps like Keepass

Overall I think the built-in password manager can be an improvement in terms of security for many casual users.

First of all, it removes another party from the trust chain. You don't have to worry about the credibility of a third party for acting responsible with your data anymore. If you don't trust iOS for securely managing your passwords, you shouldn't trust iOS at all because it already has access to these and even more critical information.

Also, the password manager can use more of the security features of the device like the secure enclave for protecting the password storage. (This is already the case as far as I know)

But of course, the security of this feature also depends on the configuration of your device. If it's not properly hardened, even more information is at risk because the access control to the password manager is done with either your pass code or biometry.

Another disadvantage is the fact, that it's currently not possible to export the stored credentials for usage in other software. While this is not directly security related, it has impact on the usability which can lead to bad practices which are weakening the security of the system.

For example, when one changes the password of a service on the iOS device, they also need to change it manually on the desktop. This could be a painful task when the password is randomly generated. The consequence could be, that users stop using random and/or complex passwords or even stop using this feature at all. The other way would be that users stop using the other devices because of this. This would result in a vendor lock-in. (Which I consider very bad because for me, sustainability is a part of security)  While the export to a file might be implemented in the future, I highly doubt that Apple will implement a feature which allows 3rd party software to sync the data.


Can client-side hashing reduce the denial-of-service risk with slow hashes?

Using servername+username as salt (or a hash thereof) is not ideal, in that it leads to salt reuse when you change your password (since you keep your name and still talk to the same server). Another method is to obtain the salt from the server as a preparatory step; this implies an extra client-server roundtrip, and also means that the server would find it more difficult to hide whether a given user name exists or not (but it does not matter much in practice).

What you describe is a well-known idea, usually called server relief, which can be applied to just any password hashing function in just the way you describe:

Client obtains (or computes) the salt.
Client computes the slow salted hash value V and sends it as password.
Server stores h(V) for some fast hash function h, and uses it to verify the V value from the client.

This is safe. The main drawback is that the slow hashing will go at the speed of the client, so the number of iterations may have to be lowered, possibly considerably so if the client is computationally feeble -- as is the case for anything involving Javascript. If the system must work with a browser on a not-so-recent smartphone, then the iteration count will have to be 10 to 100 times smaller than what could be done on the server, implying a corresponding reduction in resistance to brute force (in case the attacker steals the hash values stored on the server).

So that's a trade-off: since the busy server offloads work on clients, it can use a higher iteration count without itself drowning under the load; but since the clients are weak, the iteration count must be lowered, usually much more than it was increased thanks to the offloading; this means that the construction is not worth the effort. Usually.

Of course, if the clients are computationally strong, e.g. this is a native-code application on a gaming machine, then server relief is a good idea and will look like the way you describe it.

Another possibility is offloading the work to another, third-party system, e.g. other clients (already connected): this can be done securely if the hash function includes the necessary mathematical structures. Such offloading is know as delegation. To my knowledge, delegation is offered by only a single password hashing function, called Makwa (see the specification), one of the candidates of the current Password Hashing Competition.


What uniquely identifies my device to my ISP?

Like the previous answer mentioned, MAC addressees are strictly limited to the layer 2, which means that they will never get routed on Internet out of your personal network. However, if you feel unsafe about the security of your own local network and want to modify the hard-coded properties of your network interface card, it is possible to use MAC spoofing techniques on your operating system. There is also some software tools to do the same thing with a graphical interface.


Steps to neutralize someone who has my Wi-Fi password

If you give him the wifi password there's not much you can do to prevent him from monitoring wireless traffic. With typical consumer-grade hardware your only options to partially protect yourself are to set up a guest network (not sure if that's available on your router) or buy a second router and connect both to the network. But neither of those are perfect solutions and the only real solution is to not allow him on your network at all.

If you must give him network access, I would recommend using a VPN on all of your computers to prevent most packet-sniffing, and lock down the firewall and prevent any sharing features on the OS.


Unable to get John the Ripper to crack PDF password

To quote the output from your first command:

Use the --show --format=PDF options to display all of the cracked
passwords reliably

You weren't using the --format=PDF with your --show.


Is it helpful to slow down the password reset function?

There's no need to make it possible to enumerate usernames via the password reset function. Simply offer a box for an email address (or username, if email addresses aren't guaranteed to be unique in your system), and any time somebody enters one, give them a message saying "if we have (that address|an address corresponding to that user) in our system, we have sent an email. Please check your email, and note that it may take a few minutes for the message to arrive. The email will be valid for [some short time]."

If you want to slow down attempts to abuse the password reset system anyhow, a good CAPTCHA is probably a better bet than an artificial delay.

Also, I echo everything in @neonprimetimesecurity's second paragraph, with the addition that not only should the link be cryptographically random and unguessably long, it should no longer work after one use regardless of the time remaining until it expires. (You can make "one use" mean "once the password is actually reset" if you want, sometimes people run into issues with email scanning services that request every URL in an email and end up invalidating links before the user gets them.)


Can I share what password hash function I used in a public report?

Should you make the algorithm public?
Trying to hide implementation details (such as which hashing algorithm you use) to preserve security is the very definition of security through obscurity. There is broad consensus that obscurity should not be your only line of defense.
If you need to keep your hash algorithm a secret, you are doing it wrong and need to pick a better hashing algorithm. When you use a good algorithm, there is no reason not to tell the world about it since they won't be able to crack your hashes anyway.
Also note that in your case the salt will give you away. If someone gets hold of your database, they will be able to read what algorithm was used from that. So obscurity does not make brute forcing harder here. Advertising a weak scheme, however, might encourage attackers. A strong one could have the opposite effect. The point Mike Goodwin makes in his answer should also be taken into account.
Is crypt() secure?
The relevant question to ask is therefore if crypt() is secure enough. Let's have a look at the PHP manual:

password_hash() uses a strong hash, generates a strong salt, and applies proper rounds automatically. password_hash() is a simple crypt() wrapper and compatible with existing password hashes. Use of password_hash() is encouraged.
Some operating systems support more than one type of hash. In fact, sometimes the standard DES-based algorithm is replaced by an MD5-based algorithm.

The standard DES-based crypt() returns the salt as the first two characters of the output. It also only uses the first eight characters of str, so longer strings that start with the same eight characters will generate the same result (when the same salt is used).

The function uses different algorithms depending on how you format the salt. Some of the algorithms are very weak, and the strong ones might not be available on all systems. So depending on the algorithm used, there are a number of problems here:

For some algorithms crypt() only applies one round of hashing. That is too fast, and will enable a brute force attack.
Under some circumstances crypt() will use MD5, which is known to be weak.
Only using the first eight characters completely nullifies the benefits of long passwords.

I therefore suggest that you  switch to password_hash(). It lets you use bcrypt - a tried and tested algorithm. Then you can proudly tell the world about your hashing scheme.


What's the risk from an SSL page (HTTPS) that serves some of its content unencrypted (nonSSL, HTTP)?

If someone can inject my JavaScript code into the page, for instance by hijacking an unsecured connection, then they can basically take control of entire page.

For instance, let's say you're trying to log in to That Website That Stores All Of Your Personal Information™, but one of the JavaScript files is served over an insecure connection. A rogue employee at your ISP intercepts this one connection, and injects JavaScript code that, when you click the "Log In" button, takes the username and password you entered and sends it to himself. Now he has control over your login information and can potentially steal your identity, based on the information that he can find on your account page (such as full name, address, phone number, last four digits of your credit card number etc.)


How will microvirtualisation change the security field, if at all?

Isolating the browser in a specific jail that it cannot escape is meant to contain damage: if the browser is hijacked, at least the attacker will not obtain immediate access to the rest of the machine. However, whoever hijacks a Web browser can do everything that the Web browser normally does, including accessing your Web secrets (cookies, stored passwords), grabbing everything you type in the browser (including passwords on Web sites), and contacting arbitrary external servers. Everything you do through the browser is then at risk, and, nowadays, this is probably most of what you do at all with your computer.

In other words, the sandbox provided by Bromium protects everything, except that which is essential. It is not bad, at least conceptually, but it would be a mistake to believe that it makes everything safe.

The best that Bromium can achieve is the software equivalent of having a specific, dedicated, air-gapped machine for Web browsing -- and that's assuming that the isolation layer is "perfect", which is a bold claim. Also, this is inconvenient: when you browse the Web, you sometimes want to, e.g., save files locally and then use them. A useful jail necessarily includes some doors, which are, inherently, ways to escape the jail.

As a corollary, this will not change much the security industry.


There's a chicken-and-egg problem with the "firewall" solution: your keyboard and mouse are USB devices*.  How do you as the user tell the OS that you want to give permission to the keyboard and mouse, without using either of them?  What about if the keyboard and mouse are connected through USB ports on a monitor -- they'll be disconnected and reconnected every time the monitor is turned off and on.  I'm sure there are other situations where the "firewall" will either leave the user with no input devices and no way to approve new ones, or in attempting to avoid that situation, will automatically approve a device that it shouldn't.

*Yes, even on a laptop.  They're simply USB devices that are permanently wired in place.


Which PGP settings have been found to be vulnerable?

PGP Format Versions and Key IDs

Older versions of the PGP Key Format have several issues that potentially harm security. RFC 4880 further explains these, summarized very briefly:

higher chances for key ID collisions
fingerprint only hashes key, not size and algorithm (again, higher chance for ID collisions)
use of MD5, which is considered broken

Anyway, usage of short key IDs is considered bad practice, as chance of duplicate keys is rather high. Use long key IDs or the full fingerprint instead.

Asymmetric Encryption Algorithms

There are mainly three choices for choosing algorithms: DSA/Elgamal, RSA and elliptic curves (ECDSA).

DSA is very dependent from good random numbers during key generation and usage of the key. As there have been several issues with random number generators, it isn recommended as default algorithm any more ([1], [2], more on Wikipedia), although smaller keys are sufficient (compared with RSA).
RSA needs larger key sizes, but is considered secure for adequately large keys. 768 bit keys have been broken, 1024 bit keys might be. Keys starting from 2048 bits are considered safe and currently are default, keys of 4096 bits currently recommended by Debian and others.
Ellipctic Curves aren't broadly supported yet (GnuPG 2.1 will bring them, Google's End to End already uses them), and the security of the NIST-selected curves is still in doubt (without any proof). Generally, elliptic curves are considered safe.

I posted more on choosing keys in a Super User post.

Further Settings for Hashing and Symmetric Encryption

OpenPGP's and GnuPG's defaults do not meet highest possible security for compatibility reasons. You can change the preferred algorithms (you'd like others to use when encrypting to you) using a special signature. In GnuPG, you can create this using gpg --edit-key and updating the preferences using

setpref SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES CAST5 ZLIB BZIP2 ZIP Uncompressed

To change the preferences for signing and encrypting to others, add these lines to ~/.gnupg/gpg.conf:

personal-digest-preferences SHA256
cert-digest-algo SHA256
default-preference-list SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES CAST5 ZLIB BZIP2 ZIP Uncompressed

These list has been put together by Ana Beatriz Guerrero López and order hashing algorithms, symmetric encryption algorithms and finally compression algorithms ordered by higher entropy/security.

Not an issues with keys, but somewhat related with those settings are two rather theoretical issues. Mister, Zuccherato proposed a decryption oracle attack on OpenPGP's cipher feedback mode, which can be mitigated by always compressing data that will be encrypted; and Jallad, Katz, Schneier proposed a chosen-ciphertext attack which can be prevented by using the newly introduced (in RFC 4880) Integrity Protected Data Packet (which is a choice made by the implementation).


Safe to render data directly to DOM from localStorage? XSS attack possible?

Encoding / Decoding coupled with XSS sanitation pre save and pre dom render is best practice.

Mitigation strategies regarding browser DOM XSS attacks vary but can be strengthened with header options found here (https://www.owasp.org/index.php/List_of_useful_HTTP_headers).

While zero day vulnerabilities may exist in the various browser rendering engines these can help prevent unknown flaws in same origin restrictions which are the primary cause of XSS attack vectors.

Security is creating enough hoops to prevent the majority of attacks, monitoring for abnormalities and keeping systems and code bases patched is the remainder.


using psexec_command to trigger veil payload

I think the problem was that I was using bind_tcp instead of reverse_tcp.

I guess this might not always be the solution depending on other factors like firewall etc? But in this case it worked.

(Also, as a PS - viewing the running processes after exploiting the VM showed all of the other executables running, so I think the problem was the connection back.)


No, it is not possible to know the history of a cable (sad news).
But, good news, a charging cable cannot be used to propagate malware whatever its history (the malware can be inside the devices at each side of the cable but not INSIDE the cable)
An exception could be a specific gear, crafted by a hacker, to look like a charging cable but with some minimal computing capabilities (like this kind of gears whose take the appearance of common computer tools : https://shop.hak5.org/collections/sale/products/lan-turtle).
You can be confident with the fact that no one will use it against you until you start to store very sensitive data (like being employed at boeing) or have a hacker friend who like jokes.


What abuses can an infected webpage do to me if I'm using Chrome and Flash is disabled

First of all, except flash you have to disable all other browser plugins, the most obvious one is Java. Java has been a target in browser exploitation as much as flash has been.

the website cannot use my email and send spam mails to my contacts

If you open it in incognito mode a malicious website can't steal your cookies or other data because those data are not available to it so you should be fine, but noone can say you are 100% sure. In the case of a new browser exploit, even if it doesn't escape the sandbox but only exploits the browser, in theory it could steal data - but I've never seen something like that.
If you are still worried, you could also disable html5 rendering, as there have been browser exploits lately based on this vector, and also disable javascript (or run noscript).

there is no virus / damage to my system

If you disable plugins and run the latest chrome you are as safe as you can be when running a normal browser against those things. If you want better solutions, you go into the realm of malware researchers and running locked down browsers in virtual machines.

Of course all the security a browser can offer does not compensate if the problem is between the keyboard and the chair. If a user is tricked into downloading and running an executable, all bets are off.


Are there USB flash drives with read-only firmware?

Yes:
https://www.kanguru.com/storage-accessories/kanguru-flashtrust-secure-firmware.shtml

There exist a few other, mostly encrypted devices uses secure firmware, but this is one unencrypted drive that uses secure firmware with signed firmwares.


E-mail with just an image attached: could it be an attack?

Yup, could be an exploit for a JPEG parser, maybe trying to exploit a known vuln in the Android jpeg parser, hoping you'll open the email on your phone.
Another possibility is that it's a "beacon" or "tracking pixel" and the act of loading the image from the remote server tells them that your email address is active, the time you accessed it, your IP address, etc. Although usually that's just a 1x1 pixel image; weird to put a full large image.


URL parameter manipulation and injection

tl/dr: Whether or not you have a reflected XSS vulnerability depends
on the exact method you use to append the data.  Therefore you should
specifically check your chosen method to make sure it is safe.  Modern
javascript frameworks typically take care of these things automatically for you, but jQuery
doesn't, so attention to detail is critical.

You don't specifically have to worry about the interaction between site 1 and site 2.  The reason is because site 2 needs to be secure in all the normal ways anyway (use prepared queries, etc...).  A malicious user wouldn't use site 1 to attack site 2 (in this case), because if they wanted to they could just go attack site 2 directly.
So the main question here is whether or not site 1 is vulnerable.  To be clear, the concern would be over the possibility of a reflected XSS attack (which is what ExecutionByFork mentions in their answer).  To give a simple example, what happens if a user visits this URL:
http://mysite.com?p=">

If the way you add the p parameter to all other links implicitly treats its contents as HTML, then you will end up injecting an actual script tag into the page, executing the attackers javascript in a classic reflected XSS attack.
So the question is: do you append the p parameter in a way that potentially treats the data as HTML (creating a vulnerability), or do you append it in a safe way?  The answer to that question comes down to the specific methods you use to append the data.  Let me give two examples:
Largely safe: .prop()
Using the jQuery .prop method is safe because it falls back on setting the property of the corresponding DOM node.  By doing it this way there is no opportunity to escape the property context.  In essence, whatever you send in to the .prop method will only ever be treated as a string, with no opportunity for execution.  So code like this is safe from a reflected XSS attack:
var link = $('a').first();
old_href = link.prop('href');
link.prop('href', old_href + '?p=' + injected_data))

However this would not be safe if the user had full control of the final href (if for instance you didn't append, but instead set the href based exclusively on the user input).  In that case the user could switch the link to execute javascript like so:
http://mysite.com?p=javascript:alert(1)

Which would cause a vulnerability for code like this:
link.prop('href', injected_data))

As long as you are appending data to something that is already there, this is impossible.  However, if the href tag is previously empty, you can end up with a vulnerability (although it will only fire if the user clicks the link: not just by loading the page).
Of course, even this doesn't guarantee safe-ness, since potentially malicious data is hiding around in your application to cause problems.  You may forget that the href now contains user data, and if some other javascript grabs the href out of a link and tries to do something with it, it may cause trouble.  Also, keep in mind that this malicious data will be passed along to Site 2 when someone clicks the link, so Site 2 needs to properly secure itself (which was true before anyway, so that's not really anything you didn't already know).
Not safe: .replaceWith()
However, many other javascript methods will allow your string to be treated as HTML, which will result in reflected XSS.  In fact, there are probably more dangerous methods than safe one, so you should probably verify that whatever method you are using is actually safe.  Still, to pick an example, .replaceWith() will evaluate your string as HTML.  So something like this would be dangerous:
link = $('a').first();
old_href = link.prop('href');
link.replaceWith('click here');


What is the intended attack vector of this email?

Such question merely asks for opinions as only the sender really knows his own intent, other people can only guess.

I suppose that in your question you kept the real email address: admin@quickmediasolutions.com. It is an interesting one which can be divided in two parts:

admin: this is a common word appearing on the top of most usernames lists and frequently used for email addresses. Not only this username is common, but it is sometimes linked to a mailing list targeting several humans at once (as many chances for a malicious payload to be opened), this is just bonus, and humans with administrative privileges on whatever they are using, this is the cherry on the cake.
quickmediasolutions.com: this is just a working domain name, they are plenty of ways to get large lists of working domain names.

To me, but this is my personal guess, the attacker is sending the same innocuous email to admin@<domain> (at least, I expect other names such as webmaster to be also targeted) to the widest range of domain names possible. Using such an harmless email is the safest way to avoid spam filters to alter the results in any way.

From there all the domains tried will in one of these categories:

Those who rejected the email with an SMTP 550 Invalid Recipient message, they will most likely be left out as not being low hanging fruits.
Those who accepted the email, they will earn their ticket to the next step in the attacker's agenda.

What does this next step contains? Here again, only the attacker (or the people hiring him) may know. Maybe the goal is just to constitute a list and sell it, maybe the goal is to directly use this list and try to send some malicious payloads, maybe both...

Anyway, the idea is that such emails is most likely not meant to carry any malicious payload by itself, but is just a low-cost probe to sort targets on a wide scale.


Storing sensitive documents in a password manager

Keepass uses state of the art encryption and is considered safe now. The same holds true for alternatives for encrypting files in a public cloud drive, like a Veracrypt container or a stacked filesystem (like gocryptfs or cryptomator).

But (there is always a "but"), if you put anything encrypted into someone else's hands, he can run an offline attack against it, which is the easiest way of attacking, since no rate limiting can be applied. He can run this attack right now (which will probably only successful if you picked a weak password), or he can run it at any point in the future (when the algorithms used have been compromised).

So, if you picked a really good password and the documents you are storing are only short term (like an Id which expires every few years) and can not be exploited after their expiration (a credit card number usually stays the same on the next card, for instance) then it is probably safe to store such thing encrypted online, otherwise not.

Generally speaking, you should always ask yourself the question. "Do I really need to put this file online? Do I really need to be able to access it from all my devices at all times?". If you do not have a good reason for doing so, let it be.


What exploit are these user agents trying to use?

It looks to be trying to exploit some form of command injection.  As DarkMatter mentioned in his answer, this was likely a broad attempt to find any vulnerable servers, rather than targeting you specifically.  The payload itself just appears to just be testing to see if the server is vulnerable to command injection.  It does not appear to have any additional purpose.

In order to test if you would be affected by these specific payloads, the easiest way would be to send them to your own server, and see how they respond.  Note, that I only say this because the payloads themselves are benign;  I do not recommend doing this with all payloads.

My bet is that your server is not vulnerable, because I would have expected to see follow up request to actually exploit your server.


I have patched openssl but QUALYS says I am still vulnerable to CVE-2014-0224

If openssl was patched recently and you have not restarted all services which are using libssl you may have to reboot your machine in order to complete the openssl patching.

By running following command you can see what services are using libssl:

lsof | grep -i libssl | grep DEL | awk '{print $1}' | sort | uniq


What are the security concerns when connecting to a WiFi network?

People on the same network can read your unencrypted web traffic. They probably won't be able to access your phone data unless you have apps that open up your phone to that (FTP/SSH apps, for example)

If you want to protect the data you send over the web, only use visit SSL (HTTPS) pages while on this network.