How to setup cronjobs that do scp without saving the .pem file on either of the machines

The best practices you should be concerned with here are:

Don't re-use credentials for multiple purposes.  The two servers should not be sharing a private key.
Hobble automated processes.  Make sure that the SSH channel that is being opened up by server2 is limited to only copying files, and only to the intended directory tree.

The latter is important.  If you're saving the private key on the server 2 so it can be used via cron, you need to limit the damage that can happen on server 1 if someone takes control of server 2 and tries to use that key.  Give them an interactive login?  Very bad.  Overwrite arbitrary files?  Very bad.  Overwrite files in one tree, using a pre-determined command?  Much better.  Modern sshd_config can be written to powerfully limit a specific login.  Create a special-purpose login for this so that you can lock it down tight.  Don't use root.  No, really, don't use root.


How to assure my customer that my software is malware proof?

Two parts to this question:

  How do I show there isn't any malware in the product I'm selling?

Have a trusted third party scan, test, and verify that there is no malware. along with a good protocol for product transfer with a chain of custody will confirm. I used to work in this field and there are multiple penetration testing and scanning companies out there.

  How do I show that my application cannot be infected by malware (malware proof)?

This question can go down a rabbit hole. I would never tell someone that your application is malware-proof unless it only broadcasts out, has read-only filesystem, and is locked inside a safe with every hardware level I/O disabled and covered in epoxy.

If this isn't the case, I believe you can list the protections you have that make your device "malware resistant". Is there firmware scanning (checks for changes against a signature)? Is there antivirus installed? Does it have application whitelisting, etc. That, plus the 3rd party verification above should be a fair answer to your customer.


Got a paypal confirmation code when I don't even have an account?

I wouldn't be so concerned, yet, as it's quite probable that this was merely a mistake in entering information.

Paypal sends a confirmation when you first set up 2FA (two-factor authentication), to verify that you've entered your number correctly. If you don't have a paypal account, the most likely cause of your receipt of such a text is that somebody has tried to set up 2FA for their own account, but mistyped their number as yours.

In theory, they shouldn't be able to validate using your phone number (unless they have access to your phone), and so Paypal will reprompt them for a different number.

If your email address has been used, then you might have something to worry about! As Paypal uses email address as the primary factor of authentication (you can't sign up or login using the phone/text factor alone), the only person who should have access to use Paypal with your email address is you! There's no information in this question to suggest that this is the case, as you haven't indicated that you received emails from Paypal, so I'm going to assume this is out of the scope of the question. Suffice to say, if this were your case, secure your email account and work out what to do with nefarious (or perhaps, lack of) funds...

In addition to sending a confirmation when you first set up 2FA, Paypal will send a confirmation for every login there-after (providing you managed to successfully complete the challenge during confirmation). As you haven't mentioned receiving multiple such messages, I'd suggest that your receipt wasn't one of these.

Even if someone has successfully used your phone number to authenticate (implying that they somehow obtained the verification code sent to your phone in order to successfully set up 2FA using your phone number), there's still much less to worry about than the email address compromise scenario above. It's possible that someone could have compromised your phone (in which case, you'd need to restore your phone to factory conditions and reset all associated passwords), but again, there are other  much simpler explanations to be aware of.

For a start, an attacker might not need to compromise your phone to intercept those 2FA codes; some attacks involve keeping you busy (literally; the attacker will call you while Paypal is trying to call you, as the code can be retrieved as a phone call for the visually impaired) so that the Paypal verification code goes to a message bank service. So make sure your message bank configuration is correct, and your missed calls aren't being forwarded to some nefarious message bank service.

Even still, thanks to VOIP forging attacks, attackers can retrieve such a verification code from your legitimate message bank service by making a call from your number (even though they haven't got your SIM card) to your message bank. So better yet, disable the message bank service altogether!

However, again, I note that you've not mentioned any symptoms of message bank compromisation, so I'm going to assume that's also irrelevant here. Be vigilant of Paypal confirmation messages sent to your message bank (or disable your message bank entirely)...

In summary, it's most likely that someone merely entered their own (very similar) phone number incorrectly, and you won't receive another verification text. However unlikely, it's possible that someone could have access to your phone, or your message bank service, but I wouldn't worry about that unless you see symptoms of such a compromise... Always be vigilant of such compromises!

To clarify, Paypal will send a confirmation:

when you first set up 2FA (and this could be a mistake, which would result in Paypal correcting the issue very soon)
providing you successfully set up 2FA, for each login there-after (and this would be your indication to get on the phone to Paypal, remedy the issue, and work out what else was compromised)


Is Linux kernel supported by Linux Mint 17 LTS vulnerable?

Linux Mint founder and lead developer Clement Lefebvre responded to these accusations with a blog post on segfault.linuxmint.com in 2013.

I hear [Oliver Grawert, a Canonical-employed Ubuntu developer] was more opinionated than knowledgeable and the press blew what he said out of proportion. I wouldn’t mind too much, if we weren’t finding ourselves answering questions from panicked users rather than working on what matters right now (i.e. Mint 16 RC).
So I’ll be brief.
About package updates:
We explained in 2007 what the shortcomings were with the way Ubuntu recommends their users to blindly apply all available updates. We explained the problems associated with regressions and we implemented a solution we’re very happy with.
Anybody running Mint can launch Update Manager -> Edit -> Preferences and enable level 4 and 5 updates, thus making their Linux Mint as “Secure” and “Unstable” as Ubuntu.

HowToGeek.com summarizes the argument this way in their blog:

Linux Mint’s primary argument is that “blindly” updating packages like the X.org graphical server, bootloader, and Linux kernel can cause problems. Updates to these low-level packages can introduce bugs on some types of hardware, while the security problems they solve aren’t actually a problem for people who use Linux Mint casually at home.
[...]
The real disagreement here is a philosophical one. Ubuntu errs on the side of updating everything by default, eliminating all possible security vulnerabilities — even ones that are unlikely to be exploited on home user systems. Linux Mint errs on the side of excluding updates that could potentially cause problems.


What consequences could there be to the continued use of an operating system without updating?

Even if I do not have the system updated and having all of this configured, what problems could it bring me in the event that one is presented?

Lots of applications use the OS libraries and functions for doing mundane tasks, such as showing videos or pictures, or drawing a UI. A vulnerability in one of those libraries may affect your browser, even though the browser is fully updated.


This boils down to a basic networking problem: if the exploit requires you to connect to a listening network service on the target (e.g. exploiting BlueKeep requires you to connect to the RDP service running on the target), you need a way to connect to the target by IP address. You mention the target is behind a NAT, and that port forwarding is not configured. So how would you address the target?

If you launch your exploit directly at the WAN address of the NAT device, it doesn't have any rules set to deal with the traffic, so it will be dropped or rejected. If you launch your exploit directly at the internal address of the target, it won't get anywhere since it shouldn't route across the internet.

Basically, you are out of luck unless port forwarding is configured (either manually or through something like UPnP), or if you can get a shell on another device on the target's internal network to pivot with.


Why would the session ID entropy only be half of the length of the session ID?

This bit "if your session id is made of 128 random bits" is the misunderstanding.

If your session id is 128 bits long, then that is not 128 random bits - it is probably only about 64 random bits, encoded as a 128 bit string.

Remember, your session id is not a number - it is a string identifier, that might be representing a number.
If the session id is constructed as a hexadecimal number, represented in string form - then each random byte would take up TWO characters in the session id string. This is where that "half the length" comes from in that quote.
However note the previous section on that page - there are other implementations (such as ASP.NET), where the random bits are not represented directly in string-hexadecimal, but are instead base-64 encoded - which results in only 1/3 size increase (or 25% of bits are not random). In which case, 160-bit session id actually gives 120 random bits.

TL;DR: if your session id is 128 bits long, not all of those are random.


Does the saying "physical access = game over" apply to smartphones, too?

"Physical access = game over" is an over-simplification. It absolutely boils down to the outcome of a threat assessment, or what the vendor needs to protect and to what level. The direct answer to your question is a great big 'it depends'.

Smartphones are no different than other devices to the extent that they are computers running an operating system of some description handling data of some kind that interact with other computers or people in some way via peripherals.

The class and range of attacks a device is susceptible to when physical access is possible is very different to the type of attacks it would be susceptible over a network. Conversely, the impact on the ecosystem is also quite different and it could be as impacting or worse on the network side.

Modern/recent operating systems and smartphone hardware have multiple methodologies that aim to secure user data from attackers, whether by means of physical attacks or otherwise. Even "physical attacks" can vary between occasional access (a few minutes, casual access) to unlimited time and expertise in micro-electronics in a lab (such as forensics investigations). But there are aspects that can defeat some (or all) of these features such as local configuration of the device, having weak passwords, guessable (or no) PIN codes, etc. Online backup services, cloud based accounts (Apple/Google) aid in these vectors since most of the data in a device ends up mirrored on the cloud in some way.

However, not all smartphone hardware is born in the same way and not all operating systems in the field are implemented to the same security strength, so there are attack vectors whereby full access is possible against certain hardware/software combinations provided physical access is possible.

This is a very short summary, there is scope to this matter to write books.


Blocking attack traffic at the firewall will mitigate an attack designed to overwhelm server CPU or memory resources, but most high-profile attacks simply send a flood of data aiming to exhaust the target's network bandwidth. In this case the attacker doesn't care if you are blocking the data, because by the time your firewall can block it your network bandwidth has already been consumed.

For an analogy imagine if you owned a shop in a mall and a competitor sends a flood of fake shoppers to crowd your store, intending to prevent real shoppers from being able to enter. You can learn to recognize these fake shoppers and turn them away at the door, but it won't do any good because your store's entrance is still jam packed with fake shoppers. The problem would need to be dealt with upstream where there is more capacity, for instance at the mall's entrance.


How often, if at all, should I rotate my passwords?

Quick answer: You shouldn't bother rotating a password unless stolen.

These days even the NIST has dropped its recommendation about password rotation.  In short, the biggest danger for passwords is reuse.  If you are exclusively using strong unique passwords then you have no reason to change it unless you know (or suspect) it has been compromised.


Spoofing an NTP server to allow bruteforce on any smartphone

Answer: No, a bruteforce attack would most likely fail.

http://www.payetteforward.com/my-iphone-is-disabled-connect-to-itunes-fix/

According to this site, and anyone who has ever been a mean big brother, there are only 10 times you can attempt to unlock an iPhone before it is completely locked and needs to be restored.

1-5 failed attempts - The phone will not lock.

6 failed attempts - The phone will lock for one minute.

7 failed attempts - The phone will lock for 5 minutes.

8 failed attempts - The phone will lock for 15 minutes.

9 failed attempts - The phone will lock for 60 minutes.

10 failed attempts - The phone will be disabled and will need to be restored.

So, as previously stated, 10 attempts will be your maximum. Also, Apple has released several new ways to set a passcode on your phone without having the use the 4 digit numeric code, which has a maximum of 10,000 passcodes (0000 - 9999). Users can use a 6 digit passcode which has a maximum of 1,000,000 possible codes (000000 - 999999), or even a phrase, which has a much greater number of possibilities for passwords.


OAuth2 - Is it safe to return the access-token to the user?

I think you are speaking of the implicit grant which return directly an access token to the client. You have better time to directly look at the RFC.

My thought is it is safe if you use https. If you use JWT (json web token), the access_token can be signed (JSON Web Signature (JWS)) and encrypted (JSON Web Encryption (JWE)) in the payload.


This looks a lot like a XY problem: you want to solve X problem doing Y, but don't know how to do Y, so you are asking about Y here.
You are trying to use true secure random numbers and don't trust urandom and want to increase the entropy pool so you can use random. Right?
Don't use /dev/random... That's why /dev/urandom exists. It's seeded by /dev/random, and uses a very strong algorithm to generate random numbers in a non-blocking way. The u on urandom usually means unlimited, so it will never run out of random numbers, unless you are using a diskless station (or a router, or a live CD distro) seconds after booting before /dev/random had time to build some entropy.
Some people will argue a lot about random/urandom, that urandom is not secure enough, that only random have true random numbers, and so on. Don't listen. Use urandom cryptographically secure pseudorandom number generator and be happy. And using random can be a liability and create an incident: it blocks. And that can lead to a DoS not only on your application, but on every other application with developers thinking that using /dev/random is the way to go.
So, if you are loading a large file full of random data, why rely on random or urandom at all? Just read the file. You can even use urandom to define the position where you will read, store the number of records read from that file, and block after reading the random file enough times. It would be terrible for security (the random file is very predictable if someone get a hold of it), performance will be worse than reading urandom, and you have to keep a look on the read count to send another file before the randomness runs out (or it blocks like random).
And Thomas Pornin already wrote about this as well, and this page debunks a lot of myths about randomness too.


SQLMap: How to dump tables that begin with a specific letter?


Can skeuomorphic UI design create security vulnerabilities?

Skeuomorphic design is tempting: To differentiate a product from its competitors; but at the cost of reinventing the (UI) wheel and creating absurd learning hurdles for users. No website should be so unique as to exceed a user's motivation to learn how to use it.

For security, there are few consequences of using skeuomorphic design (especially where skeuomorphism isn't the de facto UI element):

Loss of information: The chrome of Skeuomorphic UI reduces or prohibits visibility of important security context information for the user. For example, a web browser pretending to be a "racing car windscreen" or Tron-style virtual world hides the website address as "too 2D/old skool" and not "skeuomorphic".
Drowns out high priority information: The security information might be visible on the screen but camouflaged as an innocuous UI element. For example, a remote gardening program displayed as a planet nursery could have connectivity errors and warnings displayed as a cutesy wilted pot-plant. The information was there but not especially modal or explicit.
Culturally ambiguous: Translating security and safety text between languages is hard enough, skeuomorphic design assumes the underlying product ever existed in that culture. For example, a red bulb on a skeuomorphic internet radio application might mean something quite different in non-western cultures.
Hard to navigate: Most skeuomorphic applications are only visually skeuomorphic, with none of the ease and speed of use of the original 3D object; this can result in mistakes or delays that can have serious consequences in quick-reflex/high-security scenarios. For example, checking the current fuel level of car shouldn't involve dragging a visual dipstick in and out of a tank on a touchscreen.
Can not use pre-tested third party libraries: Each skeuomorphic application has custom UI otherwise why bother? Hence the security of the interface layer does not benefit from the "many eyes - shallow bugs" effect of common third party resources. For example, your checkbook application looking like a physical checkbook instead using international standards for checking information.
Difficult to audit if business logic in UI: No idea if the application is leaking information it shouldn't. Security auditors have to learn each application's custom UI to review it. For example, when website UI conventions did not exist, the pi symbol in that The Net movie was plausible on website front page.


Prevention from cross site scripting in different scenerio?

It sounds like the approach you're taking to preventing Cross-Site Scripting is black-listing specific tags.

This approach is very difficult to maintain and would not be a recommended one as there are always new tags and parameters which could allow for Cross-Site scripting coming along, so it requires constant maintenance.  A good example of the variety of vectors that can be used for XSS is here.

If you need your users to be able to use rich content on the site (perhaps for formatting text), then perhaps another option would be to look at languages like markdown which could allow users to enter richer text, without the dangers of pure HTML.


How can I write a good corporate password policy?

IMO, the criteria in a policy should be explicit, minimal and enforceable.  "Do not use dictionary words," belongs in a best-practices document or the corporate security awareness training, not in the policy.

The policy should specify things like minimum length, complexity criteria, maximum (and minimum) age for each category of password.  It is common practice to require longer passwords for accounts with elevated privileges.

Based on current GPU hash cracking performance, 10 characters chosen from 96 (upper, lower, digits, special including space) is the minimum length that should be considered and 12 would be a much safer choice.  There has been a lot of discussion in recent years about the actual value of frequent password changes.  One of the downsides to consider is induced bad behaviors.  If users can't remmeber their password because it is changed every month, they will write it down or use guessable passwords and undermine the control.

I very strongly urge the adoption of two-factor authentication, risk-based authentication and Privileged Access Management solutions.


security and the well constructed Qt plugin

As suggested by bstpierre, you cannot protect yourself against malicious users since a plugin allows by definition to run arbitrary code.

However, if you want to prevent the abuse case where an innocent user downloads a plugin which seems legit but is not, you can do some signature checking with asymmetric crypto to make sure that this does not happen.

When talking about cross-platformness, have a look at Qt Cryptographic Architecture  (first google hit on "qt crypto"). Seems to me that this is what you're looking for, although I don't have any experience with this framework myself.


Catch incoming SMS/Calls in a fake GSM Network

The problem here is that the phone is connected to your network instead of the provider's network. To the eyes of the provider the phone is offline.

What you need to try and do is instead downgrade the phone's connection to the provider to a bad enough encryption that you can crack. I would first start with jamming the strong encryption bands like 3G and 4G/LTE, and go from there.

Another option is to proxy the phone's connection to the provider through your fake BTS. I am not sure if it's possible but the idea is that your BTS appears as a phone to the provider's network while appearing as the provider to the phone, and proxies everything in between (while logging it). I'm not that familiar with how GSM encryption works and whether it's possible to become a man-in-the-middle this way. You'd most likely have to write custom code to do this.

Finally another option is to hijack calls/texts through SS7. This requires an active connection to the global SS7 network, and then you basically say to the provider "hey I'm one of your roaming partners and your customer just connected to our network" and the provider's network will now send you all their calls. You don't even need to have the phone or the SIM, and you can do that with any mobile provided you know their IMEI and IMSI. This works even if the phone is still on their network. You would guess the network infrastructure is smart enough to realize that a phone attached to their BTS can't be roaming at another provider and it's probably an attacker doing nasty things, but the idiots at Ericsson, Alcatel & co thought otherwise.

Obviously the last option is probably illegal unless you have permission from the carrier which you'll probably never get, because 1) scamming customers is more important so why waste time on this and 2) the network infrastructure is so fragile that even benign stuff can bring the whole network down and they obviously don't want that. For example see the Telenor incident where a totally unrelated pentest in a different country crashed their HLR (and thus brought down the entire network) for several hours :

  – The analysis reveals that at the time of the crash irregular signaling was sent into the Telenor network. This irregular signaling was sent by another international operator and contained types of messages that appear very rarely, the company said in a statement.
  – This signaling was misinterpreted in the software that Ericsson has delivered to Telenor’s mobile network and lead to part of the mobile traffic stopping, according to the company, which states that the error is corrected.

I suggest you check out P1 Security's presentations about SS7. Make sure to also check out the related/suggested ones as they are interesting and outline some of the attacks I described above.


Rely on name constraints or intermediate CA pinning?

I prefer option #2, as it's simple to understand, simple to implement across different stacks.

Option #1, you need to define mutually exclusive Name Constraints for the two services, possibly makes certificate issuance more difficult (additional checks need to be done before issuing cat/dog client certs), ensure the certificate chain validation library you are using properly respects Name Constraints extensions, etc.

I know you mentioned that the validation will be done on the service, which you have more control over, but if the validation has to be done by browsers, Safari/IE and possibly other browsers don't implement it properly.


Let's encrypt publishes an API. Anyone can write a client for that API, including one with malware. You don't have to ask permission, you can sit down and make it without asking any one.

The reccomended client, certbot, can be assumed to be reasonably vetted, and while not guaranteed to be bug free, there's very very low likelihood of intentional malware in it.

The reason it can be trusted is that it's a rather popular piece of software, with contributions from many persons, and an equal amount of persons peering at the software, and in addition EFF have a good reputation.


What malicious things can happen when clicking on links in email?

The common reasons for links in spam email are:

verification that your email address is valid and that it is read which makes the email address more valuable for address brokers (the link needs to have some individual part, that can be a number, but it can also just be unique word from the dictionary). This kind of link may be labeld "unsubscribe".
the link may point to a phishing site, pretending to be from well-known-company such as eBay, but just wanting to trick you into entering your username and password for that side (e. g. "your account needs to be verified"). Please note two things: In HTML emails the displayed link text and the actual link target can be distinct. There are some special characters that look like normal ones
the link may point to a website which tries to exploit your browser or plugins to get access to your computer, or trick you to manually execute malicious code (e. g. "get this video codec", "you computer is infected, get anti virus for free").
the spammer might want to get people to visit his or her website to advertise his products or opinions, manipulate polls, etc.

Uncommon:

the spammer may try to flood the target with lots of visitors. This is not effective as a distributed denial of service attack because the email is a lot larger than the data send by the browser to the target server. Reflective DDoS usually use DNS where a small query with a faked sender address can result in a much larger reply to the target site. But it may be effective to exploit some pay per click advertisement programs.

More than one point may be true.


Risks of encryption keys contained in a memory dump after a crash?

Absolutely it's possible that the memory dump could contain keys.  If all programs follow good programming practice (clear keys immediately after use) that reduces the likelihood, but there's nothing that a program can do when doing encryption/decryption in software to 100% prevent keys from being in memory.  After all, a key has to be in memory to perform encryption/decryption and if as soon as the key is put into memory the operating system crashes there's nothing the program can do about the key at that point.


How is it possible that important databases keep getting put online with literally zero security?

Two very common situations:

no one thought about it
that was not the original design, but scope creep or "temporary measures" meant that the final product exceeded the plans for review, so it wasn't on anyone's radar

As a single developer, you hold all the moving parts in your head and you touch every part of the system. You could think about the impacts of a change on one part to the rest of the parts.

In a big team with multiple stakeholders and a shifting product plan and roadmap, it is very easy for blind spots to appear.

So, the problem is not that they didn't hire an expert. The problem is that they hired quite a lot of experts, and they were all focusing on their one small part and not the whole.

Should there be someone or some process to have their head above water to review the product before it goes to production? Sure, but then, someone needs to think about the possibility of needing such a process. And when deadlines are looming, final checks are the first to be cut. You can "always clean it up after it's released using professional services" ...


Recognise tool by which file was encrypted

Unless the application encryption sticks "something" (header, a magic token, etc...) on the header in general it is not possible to know which was the application that makes the encryption.


Decrypting SSL using Wireshark on Linux vs Windows

In Wireshark (Ubuntu 14.04) you can Right Click the SSL stream, and go to:

Protocol Preferences > Secure Sockets Layer Preferences

Here you can add RSA Key lists where you can enter the password of the private key used to protect the communications.  You can also enter a Pre-shared Key or a Pre-Master Secret log file (which I believe is what you have).

Here's a tutorial on how to decrypt SSL traffic with Wireshark in Linux.

As an alternative I would look into using a proxy like Charles to act as a man in the middle to view SSL traffic between websites.  It makes it very easy to see the decrypted traffic, and you can have multiple sessions going at once.  This is ideal in a closed off network since you'll have to install their CA into your trusted store.

But this is a great way for debugging/viewing secure web traffic.


Is Apple’s latest encryption considered to be munitions grade?

According to the Export Import laws, any device that has a minimum
  level of encryption is considered as falling under munitions type
  laws.

Let's assume you're talking about the US, here, because obviously this is going to differ from nation to nation (see the Crypto Law survey map, for example).  And even within a given area, Crypto is one area where the law has had difficulty keeping up and often defaults to a more relaxed state in the lack of better guidance.

If you read the summary of relaxations to the Export Administration Regulations, you'll see it's not as clear cut as you might think.  In effect, the US no longer restricts the export of software (except to Terrorist Nations) based on crypto strength.  (See also Bernstein vs. DOJ, which was an intentional test of the rules)

  Does apple's latest oss contain that level, and if they do, has anyone
  been questioned or convicted of reentering the us with the same
  device?

I'm not aware of any examples where a laptop was confiscated by the US due to the level of crypto on a commercially available OS.  Why would they bother using such a troublesome justification, when they can confiscate it on a whim and demand the passwords with no justification necessary?

Traveling to other countries is much more of a problem.  I have read that France, in particular, has been known to confiscate laptops with modern OSes that support strong encryption.  Especially if that modern OS happens to be on a modern, expensive, sexy laptop.  The kind that the customs agent wants for Christmas.


Is it possible to have an RSA authentication subkey with a DSA master key?

You need to activate the --expert mode to select arbitrary combinations of algorithms and capabilities (inside given technical limitations, DSA keys will never be able to have signing capability).

$ gpg --expert --edit-key [key-id]
[snip, key-listing]
gpg> addkey
Please select what kind of key you want:
   (3) DSA (sign only)
   (4) RSA (sign only)
   (5) Elgamal (encrypt only)
   (6) RSA (encrypt only)
   (7) DSA (set your own capabilities)
   (8) RSA (set your own capabilities)

Your selection?

Enter 8 to create an RSA key.

Possible actions for a RSA key: Sign Encrypt Authenticate
Current allowed actions: Sign Encrypt

   (S) Toggle the sign capability
   (E) Toggle the encrypt capability
   (A) Toggle the authenticate capability
   (Q) Finished

Your selection?

Now, one after the other, enter e, s and a to disable encryption and signing and enable authentication capabilities. Finally select the key size:

RSA keys may be between 1024 and 4096 bits long.
What keysize do you want? (2048)

Continue as usual.


Grabbing a hash from a suspected sqllite3 database file

AES 256 is a form of encryption, two way. Hashes are one way.

It sounds to me like the database is encrypted with AES 256 and when decrypted (using a password/passphrase) it will allow you to browse it. SQLCipher is a full database encryption technique. When browsing it you might come across hash values, most likely in a password column.

Hashcat is for hashes, it takes the hash (which is one way) and tries to find a collission (or uses other smart tricks) to determine what password would lead to that hash.

1: Decrypt the database
2: Find the hashes
3: Let loose the hashcat! (and try to determine the hash type)


How can I execute a XSS on 302 redirect and the body on the page?

In many cases a 302 redirect will not contain a body at all.

The RFC only requires a header to indicate the status 302 and the location the user should be redirected to.

As Steffen said, modern browsers ignore the body of the redirect and directly issue a GET for the location specified in the header.


What is the default cipher algorithm for GnuPG?

TL;DR: For GnuPG 1.0 and 2.0, default is Cast5, for GnuPG 2.1 it is AES-128.

Recipient's Preferences

Per default, GnuPG will read the recipient's algorithm preferences and take the first algorithm in that list it supports (in other words, it takes the most-preferred supported algorithm the recipient asks for).

Safe Algorithms

If no preferences are given (or --symmetric is used for symmetric encryption using a passphrase), it chooses a "safe" one. Safe means, one that must be or should be implemented. Which one this is depends on the version of GnuPG and compatibility level chosen. You can easily verify this by starting a symmetric encryption, passing one of the compatibility levels (or none, which implies --gnupg):

gpg --verbose --symmetric
gpg: using cipher CAST5

Strict RFC Compliance

On the other hand, if enforcing strict OpenPGP compliance following RFC 4880, it drops to triple DES:

gpg --rfc4880 --verbose --symmetric
gpg: using cipher 3DES

The same applies if enforcing RFC 2440 using --rfc2440.

GnuPG 2.1 Defaults to AES-128

GnuPG 2.0 also uses CAST5 with the default --gnupg, while this default was changed to AES-128 in GnuPG 2.1:

LANG=C gpg2 --verbose --symmetric
gpg: using cipher AES

(AES without further specification means AES-128 in GnuPG)

GnuPG 2.1 uses the same algorithms for the RFC-compliant settings.

Digest Algorithms

For digest algorithms, similar algorithm preference inference is performed. If --verbose is set as an option, the used algorithm is printed.

An exception is the Modification Detection Code Packet, which only allows SHA-1 with no algorithm choice as defined by the standard.


Deploy intranet application with SSL certificate

AFAIK setting the exception in each users browser is the only way to get rid of that message when using a self-signed certificate.
But: If your company has a wildcard certificate you could define a sub domain, that is just accessible in local net.

If your company doesn't have the wildcard certificate, you could still create the sub-domain, acquire a free SSL certificate (there are some certificate authorities lately offering ssl certificates for free) for the desired sub-domain for internal use.


Is a sensitive NAS behind a router safe?

If the NAS isn't directly accessible from the internet then the PCs are the weakest link.

An attack would focus on the PC. Then, with access to the PC, getting access to the NAS would be easy.

Attacking the PC first is easier, because
- They make connections to the internet regularly.  Web browsing and e-mail make good routes for an attacker.
- They are more complicated than the NAS, which often means more vulnerabilities.

Together this makes them much easier to hack than attacking the NAS directly.

If you have good security on the PCs (avoid dodgy sites, install good host security software and keep them patched ... ) then you are probably in reasonably shape for a small office or domestic situation.

And, I think obviously, as suggested in the comments. Disable the Wi-Fi if you don't use it.

I'm also assuming that:

You are only worried about remote intrusion.  You trust the people who use the computers and who have physical access to the system.
You aren't worried about, or have taken steps to reduce the chance of, the NAS just being stolen.  Old fashioned theft.
The router is configured securely (and kept up to date with security patches as well). And by configured securely that I mean it provides NAT and you haven't enabled any risky features like the 'DMZ' or 'port forwarding' options that cheap routers merrily provide. It also doesn't have remote administration enabled from the public internet IP address.

Could you get an intrusion?

So, you've taken steps to reduce the risk.  Running AV, using modern systems and keeping them patched goes a long way.

But an attack is possible.  Despite layers and layers of additional security, companies with systems connected to the internet get hacked frequently.

How could this happen?

You can divide the remote attacks into two categories.

Targeted attacks - where someone is specifically targeting your data.
Un-targeted attacks - where someone is trying to hack a bunch of computers, and by chance your computer is on their list.

Targeted Attack

Target attacks are expensive and/or time consuming activities for an attacker.

They might need to write a new virus, one that isn't detected by the Microsoft AV.  Then they could send it to you, via e-mail or perhaps a link to a web page.

It might need someone to click on the link, or perhaps they need to use a new vulnerability which hasn't had a security patch released yet.  These are known as zero day
vulnerabilities.

But these are expensive activities.  New vulnerabilities are valuable to attackers.  And writing viruses that bypass AV checks takes a little effort.  So you have to be a target that they knew about and were interested in.

From an article about attacks:

  Of the 18 attacks studied, 15 targeted 102 or fewer of the 11 millions
  hosts that were monitored. Eight of the exploits were directed at
  three or fewer hosts. The data confirms conventional wisdom that
  zero-day attacks are typically reserved for high-value targets.

(Full article: http://arstechnica.com/security/2012/10/zero-day-attacks-are-meaner-and-more-plentiful-than-thought/)

Un-targeted attacks

There's also the possibility that you get hit by a brand new attack, where you are just one of thousands of possible targets, using new vulnerabilities and/or viruses.  You'd be unlucky but it happens - but it does happen.

Though often they are just after quick financial wins - perhaps the password to your bank - or to encrypt your hard drive and demand a ransom for your data. Not every hack of this kind would result in them being interested in whatever is on your NAS.

So how safe are you?

It depends on how interesting your data is, and whether possible attackers know about it, as to whether a targeted attack is likely.  Perhaps you have some feel for this already.

I'm sure there are some stats on untarget attacks on the internet somewhere. I'll have a look for some figures.

What should you do?

Perhaps another interesting question is what else could you do if you want to be more secure. The resulting advice could form a reasonably long book.

The simplest solution: if the data is really really sensitive, don't connect it to the Internet. Don't access it from a computer that can access the Internet.

The practical alternative for the non-professional: Or, if you need the flexibility of connecting to the Internet, but still want real confidence about the security, get some security experts in, explain the level of security you need and have a detailed review done.  It's not cheap though - and you need to ensure you are getting good advice!


What are the disadvantages to the site owner to have third parties e-mails displayed publicly?

A small one.

Some spammers grab email address and domains to forge From: addresses.  If this user's email is public, that might increase the odds that a spammer will forge with it, pretending to be sending email from your domain even though the spam is actually coming from someplace else.  In which case, you might notice a slight uptick in warning notices to your maildaemon account, undeliverable email and the like.  I presume you already receive a high volume of these warnings and are already filtering them appropriately.

Other than that, I can't imagine any possible downsides.

Further, the user is right, if you have a good spam filter and know enough not to fall for a phishing attack, the risk of publishing your email address are minimal.


SIEM is nothing more than a central repo for all your monitoring systems (NIDS/HIDS) to report to. Grant it provides certain benefits but as you stated cost and deployment is rather large.

You don't buy a SIEM because your boss heard SIEM from a vendor, and thought hey we should have that. You buy them when the system grows to a size where it becomes more cost effective to add a system rather people. This varies based on how active your company is at actually looking into issues.

Remember SIEM doesn't just apply IDS system. It's quite broad and with systems like Splunk are quite versatile. Logs, SMS, email, etc which can come from all systems.


Access Control Lists - Why block a port rather than block a protocol?

Blocking a port is cheap: it can be done by a simple stateless firewall only inspecting up to OSI layer 4. It can also be done with the first packet already, i.e. even at the TCP handshake were no data are transferred yet.

Blocking by the actually spoken application protocol needs to analyze the payload (layer 7). This means that first it needs to collect sufficient payload for analysis, which means it cannot be blocked already at the TCP handshake. Then it needs to have some reliable heuristics to find out based on the first few bytes which kind of protocol this is. There are several protocols where the server sends data first (i.e. SMTP, IMAP, FTP...) in which case the firewall has no choice than to allow a connection to the server in order to get the first data in order to analyze the protocol. Allowing the connection initially already can have some unwanted side effects.

And even with payload it is not always clear which protocol this actually is. There are several protocols which use TLS (i.e. HTTPS, POP3S, IMAPS, ...) and it is often not possible to decide based on the initial TLS ClientHello what kind of protocol will be spoken inside the TLS connection.

To summarize: The best would be to block by port as long as this is reliable since this is cheap and can be done early. Additionally one can analyze the application layer for the ports which are not blocked if the actually spoken protocol is the allowed one.

  But why block it this way instead of just blocking the HTTP protocol by its protocol number?

There is no protocol number for HTTP. And "protocol" actually has multiple meanings: there is the "application protocol" at layer 5..7, i.e. HTTP, SMTP, ... . And there is the "transport protocol" at layer 4, i.e. UDP, TCP, ... These transport protocols actually have numbers used in the IP header, i.e. 17 for UDP, 6 for TCP etc. But blocking based on transport protocol makes not much sense since blocking any kind of TCP or UDP will simply block too much.


Buffer Overflow with Big Endian architecture

The stack grows "downwards", i.e. from high addresses to low addresses. In the stack diagram that you are supposed to fill, addresses are "reversed" (address 0x00000004 is below address 0x00000000, not above it), so, in that diagram, the stack grows "up".

(The point to understand here is that there is no notion of gravity in the computer; the "up" and "down" are relative to a conventional direction, which may be that of a table on a piece of paper, or that of numerically growing address values, or whatever. Here, the table indicates addresses explicitly, with arrows that confirm the convention.)

So the 0x12ab34cd word (local variable a) should appear at addresses 0x00000014 to 0x00000017, immediately above the stored frame pointer. The buffer array is then immediately above that (addresses 0x00000008 to 0x00000013).

While the stack grows towards "low" addresses (the stack pointer is decremented when a value is pushed on the stack), the buffer is ordered towards "high" addresses (buffer[0] is at address 0x00000008, buffer[11] is at address 0x00000013).

That the machine is "big-endian" matters only for the ordering of bytes within a single word. It does not impact the order of appearance of words within the stack. Said otherwise, that the stack is "growing down" is not a consequence of the machine being "big-endian".

(Note: there have been some architectures with stacks "growing up" but they are quite uncommon these days, and the exercise would make no sense with a "growing up" stack.)


Is possible to get infected by only staying connected to the Internet (nothing else)?

A few years ago (2003), there was this worm called "Blaster" (or MSBlast, Lovesan etc. - read more on https://en.wikipedia.org/wiki/Blaster_(computer_worm)). It spread by using a vulnerability in an RPC service, running on Windows XP and 2000.

At the time where it was "worst", you could get infected within minutes, if you didn't have a firewall set up. I remember installing a clean Windows XP, putting it online (without a firewall), and watch it get infected within minutes.

So to answer your question: Yes, if you're connected to the internet, you're vulnerable as long as there's open ports with services listening on them (and there's a vulnerability in the software).

So you can definitely get infected by just being online and not doing anything. Remember, even if you're not doing anything, your computer is still connected to various services online and using the internet.


"Optimal" Web Server SSL Cipher Suite Configuration

The most secure setup doesn't depend only on ciphers, but also on the tls-version used. For openssl, tls 1.1/1.2 is preferred. BEAST and CRIME are attacks on the client and are usually mitigated client-side, but there are server-side mitigations too:

CRIME: just disable ssl-compression; that's it
BEAST/Lucky13: just use TLS 1.1, no SSLv3 and no RC4, see Is BEAST Still a Threat? (Ivan Ristic)
BREACH: works only, if some conditions are met, see breachattack.com; easy and always-working mitigation would be to disbale http-compression (gzip)

For a perfect setup: SSL always impacts performance on a high level, RC4 and other fast cipher-suites might still be ok for static content, esp. when served from your own cdn.

A nice guide to understanding OpenSSL is OpenSSL Cookbook with detailed explanations also on PFS, cipher-suites, tls-version etc. pp. there are 2 blogposts that explains PFS and practical setup:

SSL Labs: Deploying Forward Secrecy
Configuring Apache, Nginx, and OpenSSL for Forward Secrecy

cipher-suites-suggestions to enable PFS also on older clients:

# apache
SSLProtocol all -SSLv2 -SSLv3
SSLHonorCipherOrder on
SSLCipherSuite "EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384 \
EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH+aRSA+RC4 \
EECDH EDH+aRSA RC4 !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS"

# nginx

ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_prefer_server_ciphers on;
ssl_ciphers "EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384 \
EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH+aRSA+RC4 \
EECDH EDH+aRSA RC4 !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS";

For a detailed nginx/ssl-manual I'd like to direct you to this Guide to Nginx + SSL + SPDY.


DNSChanger works be forcing you to use a DNS server managed by a malicious party, which thus can reply to your DNS queries with the wrong answers containing IP addresses in the control of the attacker. This way your systems connects to a different (and attacker controlled) system than you've intended and allows the attacker to hijack and man-in-the-middle your traffic.

To find out if your router is infected you thus need to find out what DNS server the router is using and compare it to your expectations. If you don't have access to the routers configuration you can use the help of some external service, which lets you visit a unique domain in control of the service and then shows you from where the DNS query for this domain came. If your router is not infected by DNSChanger then the source of the DNS query should be likely the DNS server of your ISP.

An external site which provides such service is Router Checker  service offered by F-Secure. It shows you from where the DNS request came and if the DNS server in questions looks suspicious.

Note that this shows you the DNS server used by your browser. While this is the the  DNS server provided by your router in most cases it does not need to be. For example your browser might be using DNS over HTTPS and thus is ignoring the setting provided by your router. Or you might have configured your system to use a different DNS server then the one provided by the router. This might have been done by manually, by using some privacy enhancing software or also by malware. In these cases this method will not show you if your router is infected since it does not use the DNS server offered by the router. But it shows you at least if connections done by your browser would have been hijacked, no matter if done by your router or somewhere else.


Anti-virus evasion testing: using VM with AVs to test payload detection

After some research I believe I've come to an answer. I may need to clarify my question but in a nut shell what I'm looking to do is this: I'd like to be able to test my payload against as many anti-virus engines/databases as possible. Normally I'd do this with virus total, but I'm told that if you upload a sample it increases the likelihood that my payload will become detected. In other words, samples uploaded to VT get some "special attention" and thus most tools discourage users from uploading.

My solution is to scan my sample/payload with VMs containing various anti-virus softwares. In my search I found a tool that does just this. That is, it's an open source Virus Total which I as a user retain complete control over.

Meet Malice. Malice works by spinning up docker containers which contain various AVs. Most of them are free but you can also provide product keys for AVs that have paid subscriptions. This is exactly what I was looking for. I can now run a command like malice scan sketchy.exe and it will scan against the default AV engines. While not as complete as Virus total, this is definitely good enough. Really a cool project, I hope it continues to under go active development.

While this does answer my question, someone might know of a better solution so I'm going to wait at least a few days to accept my own answer.

As @atdre mentioned, there are many other such tools.
opswat.com/solutions/multi-scanning
irma.quarkslab.com/overview.html
github.com/PlagueScanner/PlagueScanner
github.com/joxeankoret/multiav
herdprotect.com


Is image blurring an unsafe method to obfuscate information in images?

Is it possible to "de-blur" the image, if you know the algorithm and
  the setting, or by trial & error?

Here, I assume we are only considering images which were blurred using a filter applied to the image, and not as a result of a poor capture (motion/optical blur).

Deblurring definitely is possible, and you will see support in many image processing tools. However, blurring intentionally reduces the amount of information in the image, so to truly get back the original image could require "brute force", whereby a (humungously) large number of candidate images are generated, which all "blur" to the same final image.

Different types of blur have different losses, but it is possible to reverse all of them (albeit expensively). The cost of deblurring and the number of possible outcomes depends on the number of passes taken by the blur filter, and the number of neighbors considered while blurring. Once deblurred, many tools and services should be able to automatically remove many of the outcomes, based on knowing what type of image it is.

For instance, this blog post talks about why blurring content with a low amount of entropy (e.g. check books) is much less secure than blurring something like a human face.

In short, it is indeed possible to get back an image that if "blurred" will result in the same image that you provided. But you cannot guarantee that the deblurred image is the only valid deblurred version (you will need some domain knowledge and image analysis like matching edges, objects making semantic sense).

  For the naked eye, it could be difficult to figure out the blurred
  content. But could the blurring be "reverse engineered" to reveal the
  original image, or at least something that is recognizable?

It is possible that blurring does not fundamentally transform the "signature" of an image, such that the histogram is similar and allows matching.
In your case, the human eye can actually make out that this could have been the Google logo (familiar colors) but the histogram is quite different. Google itself can't identify the image and you can study the histogram and color clusters using this online tool-- the images are quite different.

If probably would be safer if you were to choose to black out the sensitive content (see post here)

I wish these things weren't possible (e.g. I used to try to go as fast as possible near speed traps so that motion blur would hide my number plates, but it never works anymore). Tools to deblur are fairly common now (e.g. Blurity) though they don't work as well with small computer-generated images (less information) as they do with photographs (see sample of what I recovered).

In terms of more references, the first chapter of Deblurring Images: Matrices, Spectra, and Filtering by Per Christian Hansen, James G. Nagy, and Dianne P. O’Leary is a really good introduction. It talks about how noise and other factors make recovery of the exact original image impossible: Unfortunately there is no hope that we can recover the original image exactly! but then goes about describing how you can get a close match.

This survey compares different techniques used in forensic image reconstruction (it's almost 20 years old, so it focuses on fundamentals).

Finally, a link to Schneier's blog where this is discussed to some detail.


The self signed ones are the root nodes, which are generally drawn on top (i.e. the tree or trees are bottom up). You can distinguish them by looking at entries where the subject is also the issuer (J and K, in other words).

After that you simply draw edges from the root nodes to the underlying nodes. So in the end you should have a branch or chain going downwards from J to S and from S to M, and finally from M to E.

F and N don't seem to have been signed by any entity, which probably means they just form partial trees. In principle it is possible to use a trusted public key instead of a certificate. Generally public keys / certificates should be signed by some entity though.


Maybe your restored files from the old machine have broken the link between EFS certificates and their associated private keys.
So, try to use Mimikatz 2.0 on the old machine http://blog.gentilkiwi.com/mimikatz/crypto#exportKeys with admin privilieges

using the crypto::exportKeys function, you can export the private keys (just pay attention to your ACL on the files)
using the crypto::patchcapi function, you can patch the Windows CryptoAPI provider loaded in mimikatz. Then, the « non exportables » private keys becomes « exportables » :)


Does my UI need to be secure if my API is?

I think you are on the right track.  As long as the API is secure and won't allow incorrect behavior, then there is no way for the UI to be manipulated to cause bad behavior directly, at least as far as the application is concerned.

The problems start when you realize that from the user's perspective the UI can't be trusted though.  If it is possible to manipulate what the user sees, then it may be possible to get them to enter incorrect information by misleading their input.  Similarly, information leakage from the UI may or may not be a problem in your context.

You won't have to worry about bulk exploits breaking business rules, since the API won't allow it, but you still have security concerns around the end user experience.


I don't believe TLS can actually improve page load times on its own. What they are claiming is that their service is optimized so that performance-improving features (in particular HTTP/2) are not incompatible with encryption, and that a website served over HTTPS (likely using HTTP/2, session resumption, etc) on Cloudflare will be faster than a website served over HTTP without their services. This is supported by their general statements on performance:

  HTTPS isn’t what it used to be. It’s faster, more secure, and used by more websites than ever before. SSL enables HTTP/2, which has the potential to make websites up to two times faster with no changes to existing codebases. Modern TLS also includes performance-oriented features like session resumption, OCSP stapling, and elliptic curve cryptography that uses smaller keys (resulting in a faster handshake). TLS 1.3 reduces latency even further and removes insecure features of TLS making HTTPS more secure and performant than any previous version of TLS and its non-secure counterpart, HTTP.

So while TLS on its own cannot improve performance (it necessarily adds a small amount of computational overhead), some modern network protocols like HTTP/2 only work over TLS. While this isn't standardized, practically all browsers require TLS with it. As such, you could argue that TLS is necessary to use protocols that improve performance, but TLS alone speeds nothing up.


What agency digitally signed Cryptowall 2.0 so that it can run without being detected?

You are technically wrong when you say "signed the virus". the CA NEVER signs any code. What CA can do, is issue a code-signing certificate. Then the MAKER of the virus do sign the code. This means the CA never see the code and you can't really blame the CA for issuing a code-signing certificate.

The Point of a code-signing certificate, is to bind the code to the person who signed it. So if the CA did a correct verification here, and the code-signing certificate was not leaked, then you should have the virus maker's personal details right in front of you, and it should be easy to get him prosecuted and liable for financial loss due to the virus.


Analyze / Sniff all packets from all devices connected to a router

Depending on your router or (switch) if it supports port mirroring, where you will be able to duplicate the packets transmitted through Mirrored Port to Mirroring Port. This function allow network administrator to capture packets of a specific port to monitor the network or troubleshoot. So you can mirror the port of your internet connection to your laptop.

If you don't have this function in your router or switch, then use the following solution for temporary sniffing/analyzing:

1) I connect my laptop to the internet using Ethernet cable,
2) then share internet using WiFi hotspot,
3) connect all device I want to analyze to the WiFi hotspot,
4) open up Wireshark on my laptop and listen to the Ethernet port.


What would be the key size for a picture used as a key?

Your most recent edit indicates that your pictures are procedurally-generated, so your key size will therefore be bounded by the amount of state required to generate an image. Yours seem to be parameterized by four floats for the initial conditions (and fixed output image size, camera location, point light location, convergence conditions, etc).

Those 128-bits of state will then be transformed into an image by an algorithm that depends solely on your provided state, so your image "key" cannot contain more than 128 bits of information. In fact, I think that entire classes of initial values produce identical outputs (e.g. when all four floats are extremely small), so your image "key" size will be strictly less than 128-bits.

There's really no benefit to touching the 128 bits of state by turning it into an image (and then somehow back) if you only reduce the size of the key by doing so.


I doubt that this can be done in the mail application itself. But since you own your own domain, you might run your own mail server and some allow you to change the mail headers. If you use postfix take a look at header_checks.

But note that mail clients leave more footprints than just X-Mailer. You can also distinguish clients by the other headers, structure of MIME boundaries and much more. It's more complex but possible.


Are popular browser extensions for anonymity as safe as Tor?

No. They are different safe than TOR!
Anonymity is complex and there is no "X is better than Y" answer.

If the extension uses a simple unencrypted proxy, for example, everyone between you and the target server can read all your data. The proxy server provider knows your IP and can log everything you do.

If it is a encrypted VPN, between you and the VPN Provider, no one on that path, like your ISP, can read your data. The VPN provider can see all your data, log everything you do and knows your IP.

If you use TOR, the data is encrypted between you and the TOR exit node in multiple layers. The TOR exit node owner (some random person which you can't identify) can read all your data. She doesn't know your IP, but does know everything you send over the connection. There are some malicious exit nodes!

In all cases, everything you do over an unencrypted connection (not https) can be read by someone.


Client side encryption of user data with user password

The biggest flaw in this scheme is that it depends on javascript code that will be transmitted to the client by the (a) server.

So, what's to keep the server (or a man in the middle) to send the client modified javascript that circumvents all the security measures? How would the client, or, for that matter, the user ever know? All the code that you write to check fingerprints, checksums, digital signatures etc can likewise be circumvented.

A related problem is other, malicious javascript code running in your Browser that can't be reliably isolated from your security-related javascript code.

This is impossible to fix. In-Browser Javascript is currently not a secure platform and all browser client-side cryptography suffers from this gaping security hole that can't be closed.

Summary of the discussion in the comments regarding the updated question

Calculating pw = sha256(sha256(user_password)) strikes me as a bad idea for several reasons.

The first one was already mentioned by AgentMe: Don't use simple hash
functions such as sha-whatever to hash passwords. These hash functions were designed to be implemented efficiently in hardware and are much, much
too fast; to hash passwords, you want slow hash functions. See AgentMe's
answer.
With this scheme, pw can be calculated if you know gk (which is just sha256(user_password)). So when someone steals your localstorage, you give him access both to the master encryption key and to the authentication/authorization token he needs to download the encrypted files. It would be better to keep the two secrets independent of each other, so if one is compromised by a third party, it's not enough to calculate the other one and break the confidentiality of the encrypted data.
Finally, you're not salting your user_password with this scheme. This means that identical passwords across your whole userbase will yield identical hash values (and there are already large rainbow tables for unsalted sha-hashes out there containing the few million most common passwords).

You suggest an alternative, e.g. gk=sha256(user_password) and pw=sha128(user_password). While this solves point 2, it doesn't address 1 und 3. Also I wouldn't recommend it because I could imagine that this needlessly provides additional information to an attacker (the same password hashed to two different hash values), even though I don't know how to exploit it.

I suggested using gk=hmac(user_password, n) and pw=hmac(user_password, m), where m and n are known, but different for each user. How you arrive at m and n is irrelevant, as long as they're random and sufficiently large to make them unique across your user base with a high probability. You could create them on the client and submit them for storage at the server, indexed by the username so they can be retrieved on other clients. Or you can have the server generate them when the user first creates an account. The values don't need to be kept secure; they're worthless without the user_password. An improvement improvement would be to use  gk=hmac(bcrypt(user_password), n) and pw=hmac(bcrypt(user_password), m) to make brute force attacks harder.

Now, I'm not convinced that this suggestion is a good idea, since hmac is designed for message authentication, not for creating authentication tokens or encryption keys, so I'd take that suggestion with a grain of salt. But it seems to solve all three points I raise, so it seems like a better solution than chaining the same hash function or using two different hash functions on the password.


Why are there very expensive and cheap SSL same type certificates?

SSL certificate price depends basically on how much the vendor feels he can charge for it. The per-certificate issuing cost is extremely small; most of it is about the manual operations to verify the identity of the requester, but that is still a lot less than what CA typically charge. Like with software, CA charge money to cover their development cost, and/or to get filthy rich.

There can be some sub-clauses about insurances. When you buy an EV certificate, you also pay for some insurance that will cover some cases of fraud related to certificates. You have to read all the fine print of the insurance contract to know exactly what you are buying. It is plausible that a 2000$ certificate comes with a more comprehensive insurance policy than a 99$ certificate.

It is also entirely possible that some CA think that by making their prices 10 times higher, they will have less customers, but not 10 times less customers, thus making the operation worthwhile. Customers are people; they tend to think about certificates as some magic things, and are not very rational about them.


PCI Compliance Password time to die change requirement

I assume you are talking about customers of the bank not being required to change their password every 90 days.
Customers of the bank are not covered by PCI; PCI dictates what employees and others working on the infrastructure within PCI scope are required to do.  To quote PCI DSS 3.2.1 Requirement 8 (emphasis mine):

Note: These requirements are applicable for all accounts, including
point-of-sale accounts, with administrative capabilities and all
accounts used to view or access cardholder data or to access systems
with cardholder data. This includes accounts used by vendors and other
third parties (for example, for support or maintenance). These
requirements do not apply to accounts used by consumers (e.g.,
cardholders).


How to deal with password schemes that can produce weak passwords?

You don't get a weak password out of a strong scheme, because there is no such thing as password strength. Sometimes we say "this password is weak", but what we really mean (that is, if the "we" that is speaking knows what he is talking about) is that "this password generation method is weak".

The important point here is that password security, just like anything else in cryptography, is probabilistic in nature. For instance, when we generate a RSA key, we are just assuming that any attacker will not guess the private key right away through sheer luck. We can live with that assumption because we know that the probability of the attacker getting that lucky is sufficiently small to be neglected. The same applies to passwords: if the generation process produces passwords with "40 bits of entropy", then this means that on average, attackers will need 239 tries to find the right one. However, they may get lucky, or unlucky, on any specific password; this is an average.

Probabilities rule our whole lives. Every single decision we take is in fact probabilistic; we accept to, say, take a bus ride because we balance the convenience of taking the bus with the involved risks, risks being a combination of the consequences of an unfortunate event and the probability that such an event occurs. Namely, we take the bus because we rely on the bus not being struck by a falling asteroid, and also because sitting close to a smelly unhygienic fellow traveller is both non-lethal and still not frequent enough to warrant travelling on foot instead.

Passwords are no exception to this rule. We use passwords for authentication because we estimate that the involved risks are low enough. A sub-theme is that attackers are also humans who take probability-dependent decisions; an attacker will not try to guess the password if the password generation method is such that his chances of success are very low. Attackers who run PC farms must think in terms of average; namely, they must think in terms of costs and bills, which are good examples of everyday averages.

Another way to state it is that the probability that you draw "correcthorsebatterystaple" (2-44 in the conditions assumed in the comic) is equal to the probability of the attacker guessing your password in one try if you got any other of the 244 possibilities. If you deem that the latter probability is low enough to be tolerated, then so must be the former.

Thus, worrying specially about the occasional "weak" password is not rational -- this is only a subcase of the average password security. It is, in fact, the same problem. You can just consider that by generating your own password, you are "just" performing yourself the first attacker's try. If you consider it that way, then you see that you are not actually giving any advantage to the attacker regardless of the password you obtained.

(It may be argued that if you apply defensive procedures, e.g. generating a new password if you find that the one you got is "weak", then you are actually shrinking your password space, and that reduces security, not increases it.)


urbanairship basic Authorization found in Mobile Application Outgoing Traffic

Using a hardcoded/shared keys for use cases like this is definitely not the correct approach. Are you sure the client didn't make a client auth request before this?
If it is indeed shared/hardcoded keys, what are the risks of doing so?
Well, that depends on the scope of that key. If the key can only share the public information, you probably are not losing a lot. If the key can be used to fetch private/personal data, then that is absolutely dangerous.
The ideal solution would be to use public/unauthenticated endpoints for public data if you want to avoid having users to log in.


can Veracode be taught to accept mitigations that it does not yet recognize

You can group all these instances and mark them as false positives. I would think Veracode provides an option to write a custom rule, so it ignores these instances when they occur.


What is an exploitation schema in this XSS attack?

Reflected XSS from HTTP headers usually isn't exploitable. You need to trick the victim into sending a request with a malicious header, and how would you do that? You can't just craft a malicious link as you would if the reflection was from the URL. There's a risk that the only person you can own with this is yourself.

However, I still see two possibilities:

Stored XSS, i.e. if your header value is displayed to someone else. This would be the case for e.g. a log.
If, and this is a big if, the site has a CORS policy (Access-Control-Allow-Headers) allowing that header to be set, you could trick the victim to visit a site under your control that makes an XHR call to the vulnerable site.


'Modern' OpenVPN (2.x, using the TLS mode) basically sets up two connections:

The 'control channel'. This is a low bandwidth channel, over which e.g. network parameters and key material for the 'data channel' is exchanged'. OpenVPN uses TLS to protect control channel packets.
The 'data channel'. This is the channel over which the actual VPN traffic is sent. This channel is keyed with key material exchanged over the control channel.

Both these channels are duplexed over a single TCP or UDP port.

--tls-cipher controls the cipher used by the control channel. --cipher together with --auth control the protection of the data channel.

And regarding security, OpenVPN uses encrypt-then-mac for its data channel, rather than mac-then-encrypt like TLS. All the CBC-related issues you hear about are due to the combination mac-then-encrypt + CBC. This means that AES-CBC for the data channel is perfectly fine from a security perspective.

(And there is no GCM support for the data channel yet. That will arrive in OpenVPN 2.4.)


How to check if a website is sending out a virus?

The best thing you can do is have a known clean copy of your site that you can compare the server's files against. Most hacked webservers that serve virus infections come from changing the content of scripting files that server is offering to clients. Look for files with different checksums or new files.

There are also cases with forums type sites where the infection will come through XSS. In an effort to hide infections from site owners, sometimes infections are only served up if the visitor has a referrer tag from a search engine in their request.

You can also run 3rd party scanners against your website. http://www.antihacksecurity.com/scan-a-website-for-virus-malware lists some of those options.

Since you're talking about your machines connected to the same server, I'm assuming you mean a LAN environment where that server also offers file sharing. Among other things, it's often very good practice to split servers that offer external facing services from those offering internal facing services. Further, that poses the idea that the server may have been compromised and then used as a launching point to infect your machines.

Identifying the particular infection will also allow you to research the most common way that it is transmitted. Most virus packages are full packages that an attacker can drop & move on. That means they'll behave the same way.

Ultimately, verification breaks down into two possible areas: scan try to find "bad stuff" or authoritatively certify that everything on your server is "good stuff." The second one is more secure, but requires the right type of environment and planning.


Leak a GOT entry using return-to-printf@plt

Yes, I think it's possible to leak an address using printf. In puts you only need to pass one argument to the function, the string you want to write to stdout, and in a case of a buffer-overflow the address of the function you want to leak. In printf you also need to pass a format specifier. There's a write-up here that demonstrates exactly that.


How to bypass mysql_real_escape_string to exploit a SQLi vulnerability?

Update: see comments below regarding proper implementation.

Original answer, before knowing this was officially documented:

  The use of function real_escape_string with substitution %s within
  an already quoted string '%s' looks highly suspect.

  There could well be a vulnerability if

  if real_escape_string not designed correctly,
  or not used in accordance with its documentation. (mis-used, perhaps with extra quotes ' or something else)

I would highly recommend using a more standard method of solving SQLi
in PHP. One that involves ? substitution is best. However there may
be another sound encoding method available. Such methods usually add
their own quotes internally, in which case adding quotes ' in your
code would be unnecessary.

I did notice one other thing about that code. Where does PREFIX come
from? If this is user-provided then you obviously have an SQLi
vulnerability. On the other hand, if it is simply a hard-coded or
well-sanitized value then you are OK with that one.


How to send sensitive data through an email?

In the general sense, you can't - if it is attached in readily usable form. However, if you can communicate a password out-of-band (perhaps by a phone call), and the recipient is willing to unzip your documents, you could send them in an encrypted zip file. Be aware, though, that some email filters will delete any zip files that they can't open, and that once the data has been unzipped, it may well be sitting around on someone's computer.

It's very hit and miss as to what companies will accept though.


I can think of following scenarios:

Since you are processing your data and then carrying out a DB call, you should ensure that you used prepared statements in your webserver. That will take care of all your SQL Injection attacks
If you are presenting the data on your webpage, then ensure you are sanitizing your input to prevent a Stored XSS attack.
An attacker can change the order of the cells in CSV file inorder to crash the server. You should make your code independent of the cell ordering in CSV file (it is very easy to implement). It is also a good to have feature

In your case, you should be worried about secure coding of your application and handling different edge cases in the structure and contents of the file.
IMHO All the applicable attack vectors here will be related to the data present in the files.


The AES Crypt implementation hashes a password 8192 times to generate the key. Is this necessary?

RSA's standard for password-based cryptography recommends "at least 1000" iterations, so the factor seems to be in the ballpark.

With 8192 iterations, you are essentially increasing the time needed to complete a brute-force attack by a factor equivalent to adding 13 bits of entropy to the password or 2 alphanumeric characters (with respect to brute-force attacks only). This is a good way of thinking about it because it is independent of increasing computational power.

The question is: given the security of the passwords you or your users will be using, is it feasible to brute-force it? If you add 13-bits to it, is it feasible to brute-force it?

If your users are using strong passwords, the answer is probably no to both. If your users are using a dictionary word, 13-bits is probably not enough to push it into secure territory. Your answers to these questions will change over time as computers become more powerful.


Partitioning database to enhance security/anonymity?

The entity being able to combine the data later will probably be your "security" bottleneck.

You can of course have a relationship:

       user
     /      \
    A        B

and hope that an attacker only gains access to A or B or potentially even BOTH but somebody somehow needs to have knowledge about how to piece this together again and that's where your bottleneck is going to be. However, let's say that someone manages to attack your bottleneck, they might only be able to retrieve the linking of datasets to users but not necessarily gain access to the data itself. Let's say you have
three servers A,B and R where A,B store raw data and R stores the relationships. How would you do access control? Would you encrypt the data so that only the user himself can decrypt the information and piece it together? A and B don't know who you are so you can't really do access control on those data sets because if you store WHO has access to what data on A and B you're already linking it to a user again.

How does your application then access the data? Do you need to run computation on the data? How do you do that if you don't know the relationships?

For me... this is just way too broad. You might get a meaningful answer for a specific scenario but probably not in the generic case.


Shouldn't popular cryptographic hash functions encode the length of the input data in the output?

You're missing another downside: it tells the attacker the length of the plaintext.

In some cases this is considered sensitive information. If I'm brute-forcing passwords, for example, you're telling me that I can skip trying all passwords except those of the specified length. Cool, thanks.

  Collision attacks usually require the attacker to modify the length of the data (by appending more blocks to the existing data or something like that), don't they?

I believe you're describing a length extension attack. The real cryptographers would probably roast me for saying this, but I naively have a possible solution of padding the massage prior to hashing (at which point you can drop the whole length encoding and just use a traditional hash function): _(really, don't go building software based on this, I don't guarantee that it's secure).

hash( 0*(256 - (len(msg)%256) ) || msg)

Then when the attacker tries to do a length extension attack by concatenating msg2 to the end:

hash( 0*(256 - (len(msg||msg2)%256) ) || msg||msg2)

they will have a different number of padding 0's, which changes the massage prefix and totally breaks the length extension attack.

(The more I think about this, the less I want to stand behind the idea. I should probably spend some time googling "length extension attack mitigation" rather than sitting here and speculating)


Algorithm for HTTP flood attack detection

I would suggest using a tool that is geared towards log aggregation/parsing such as the ELK stack (Elastic search, Logstash and Kibana). After a couple of hours of research into the context and tools, you will be able to set up a logstash pipeline and a filter plugin that will suit your needs.

Parsing apache logs in particular is a very mature use case.

Regarding your specific question, some good generic starting points would be:

Detection of randomized subdomain requests ([gibberish].yourdomain.com), multiple and isolated requests targeted at a specific resource of your site (i.e an image, text file etc..)  coming from random IPs, abuse of forms present on your site (multiple requests to your target script) or abusive entries in fields that traditionally have processing attached to them (uploads of malformed/large files).

Considering the context of your question, I would suggest basing my PoC on a specific common design flaw or popular package vulnerability in order to illustrate the detection techniques that might be relevant.

Perform the following search on google and it will yield DoS vulns that you can replicate and have working exploits that you can build countermeasure against: "apache dos site:exploit-db.com".


That's funny, I was just reading about SPADE yesterday because I had a similar question. I'd be curious to hear more about what you come up with.

Meanwhile, I can point you to some other resources. There has been some talk about anomaly detection on the dailydave mailing list over the past two months, but no particular tool or technique stood out and there was a bit of a blast over a missing video. Perhaps worth checking out, though.

My introduction to anomaly detection was around a decade ago via Ourmon (free, open-source software) and Lancope (commercial). Shortly thereafter, SPADE and Bro started to appear on the scene as potentials in the open-source space. I had always been curiously into NetFlow data as an anomaly source, and today you have FOSS tools such as FlowMatrix or FlowBAT if you prefer the CERT SiLK tools.

I have run across one use of Bro (via the SecurityOnion project) to perform DNS anomaly detection. Typically, others are integrating their detective capabilities into Splunk (as there are many books written) -- and in particular, the Prelert toolsuites are focused in that direction (with demos, much like Splunk). To that end, I also found this page on syslog anomaly-based log analyzers. Finally, a tool called Skyline appeared interesting, albeit starting from a more ITOps perspective.


BTLE pairing: Where does the code come from?

Bluetooth 4.0 pairing depends on both devices agreeing to the same 128-bit "temporary key". In most practical cases the key is generated (zero-extended) from a passkey. According to the spec, the passkey is generated pseudo-randomly.

(all quotes from https://www.bluetooth.com/specifications/adopted-specifications)

  The Passkey Entry STK generation method uses 6 numeric digits passed out
  of band by the user between the devices. A 6 digit numeric randomly generated passkey achieves approximately 20 bits of entropy.

The specification also determines which device generates (and displays) the key and which one expects user input.

The bluetooth pairing protocol uses a "bit commitment" scheme, designed to prevent MitM attacks. Basically, both devices exchange a "confirm value" based on multiple parameters including the temporary key (passcode) and a private random number. The private random number is disclosed at a later stage, proving that the device indeed had known the passcode at the beginning of the process.

  The passkey Entry method provides protection against active “man-in-the-middle” (MITM) attacks as an active man-in-the-middle will succeed with a probability of 0.000001 on each invocation of the method.

The scheme was found to be fundamentally flawed, allowing an active MITM attacker to determine the passkey on-the-fly and pretend that it was known before pairing. A detailed description of the flaw can be found here: https://eprint.iacr.org/2013/309.pdf.


You can use the same trick as can be used with hidden inputs:

<link rel="canonical" accesskey="X" onclick="alert(1)" />

On Linux, use ALT+SHIFT+X to trigger the payload. IMHO it's enough to report the issue and get it fixed, but it does require some unlikely user interaction.

Other than that, I see no way to exploit this in a modern browser without further code.

While the link tag supports the onload attribute, it only fires when something is successfully loaded, eg:

<link rel="stylesheet" href="http://localhost/test.css" onload="alert(1)">

If your injection were <link href="[user input]" rel="canonical">, then you could exploit it via http://somedomain/somecsssfile.css" rel="stylesheet" onload="alert(1).

The WHATWG spec defines that the first attribute must be used, so it is unlikely that any browser would use the second, so this will not work for your case.

I tried all other event attributes, and none trigger on a normal page load.

This blog post states that this would be exploitable under IE7 and IE8 by injecting a style attribute which then uses an expression to execute JavaScript.

If there is additional JavaScript code that insecurely processes elements, this might also become exploitable (see here for an interesting example).


Vulnerabilities and potential scale for sensitive data transferred in plaintext, involving credit card payment information

Credit card information should never be sent over plaintext. It will also violate PCI.
Credit card information should only be sent using encrypted transmissions. Ideally, in 2020, that is: HTTPS with HSTS, a certificate signed by a trusted CA, TLSv1.2/1.3, and a secure "A" ciphersuite configuration. To go the extra mile, check that all 3rd party scripts are using sub-resource integrity in their HTML tags and are also sent over HTTPS.
All of the above settings are used in tandem to ensure transport security from the client to server: HSTS ensures only HTTPS is being used, a certificate signed by a trusted CA ensures the user may safely trust the certificate, TLSV1.2/1.3 are safe to use to exchange keys (TLSv1.0/1.1 have issues), an "A" ciphersuite configuration does not have any known flaws, and sub-resource integrity will ensure that the user's browser does not interpret any malicious JS modified by a 3rd party on a potentially hacked website (for example, jQuery JS files on the jQuery CDN.)
The threats posed by transferring credit card information over plaintext is namely information disclosure via MITM. However, plaintext HTTP is also vulnerable to integrity and even repudiation -- anyone in the middle can modify traffic as well as viewing it. Users may also hesitate to send CC information over websites which do not have the padlock or HTTPS in the URL.


Should web applications that are only accessible from a LAN be held to the same security standards as publicly accessible websites?

Yes. Absolutely, yes.

Your assumptions about your internal network have issues:

you assume no attacker would ever gain control of any device in your network, which is a bad assumption to make (see http://www.verizonenterprise.com/verizon-insights-lab/dbir/, https://www.fireeye.com/current-threats/annual-threat-report/mtrends.html). Attackers will go quite some length to gain a foothold in a network, and there is a commercial marketplace for buying compromised hosts within specific companies.
you assume only users have access, but what about third parties, such as managed service providers, contractors, temporary employees? Also, what happens if someone breaks into wifi? Or gains access to a wired port (e.g. a pwnplug)

More generally, there is also the matter of why have two sets of practice/standards, when surely it is more efficient to have a single standard that applies everywhere?

You might find it useful to read Google's paper on BeyondCorp, https://static.googleusercontent.com/media/research.google.com/en//pubs/archive/44860.pdf.

The tl;dr being that in their conception of the network, you make assertions about users and devices, but not about the network - mostly because it is simpler to assume all networks are hostile, than it is to assume some are, and some are not (in part, the cost of misclassifying a network as safe could be very, very high).

One possible reason for such an approach is that the Snowden leaks revealed that previous assumptions about the safety of their network were incorrect - the NSA tapped into fiber in order to tap into (at the time unencrypted) inter-DC data flows.

I think the basic answer to your question is that the boundary/demarcation point for security is no longer at the edge of your network, it is the devices on your network. And as such, it is both simpler, and more realistic, to focus on preventing categories of attacks/abuse, rather than to consider that one network is 'better' than another. You may not need quite such strong controls on an internal DMZ as you would on an external one, but assuming that your network is secure is a dangerous assumption to make.


When to use Session key or Premaster Key

Pre-master key and Session keys are two different things.

Pre-master key is used to provide a greater consistency between the cipher suites that belong to the client & the server. All your subsequent keys are derived using the pre-master key.
Read this link for more details: What's the point of the pre-master key?

Session key on the other hand is the symmetric key that you will to communicate further. Session key is derived using the pre-master key.


Executing XSS payload when "http" is added to payload

No, if you can't change the part before the colon, you are guaranteed to always produce a HTTP URL, no matter what you append.

This follows the Uniform Resource Identifier (URI): Generic Syntax RFC 3986.

  Each URI begins with a scheme name [...].

The syntax of the scheme part is specified as follows:

URI  = scheme ":" hier-part [ "?" query ] [ "#" fragment ]
...

So, no XSS is possible here and you are limited to comparatively harmless vulnerability classes, which deal with HTTP URLs, such as open redirects or referer leakages - depending on your scenario.


Why pull upgrade from production server rather pushing them from development server?

The primary concern is not giving developers write access to production systems. This goes well with the principle of giving someone the least amount of privileges needed to perform a task.

Giving developers write access to production systems poses a few risks. Developer machines are used to surf the net. It's expected because developers need to browse documentation, download software, use Stackoverflow etc. There is a slight chance of them getting compromised by malware. This of course spells disaster if the same developer machine has write access to production. Secondly, giving production write access to developers might open them up to the temptation of pushing to production directly, bypassing things like having review systems in place, ensuring all commits pass unit tests etc. This could very well lead to sloppy code which further opens up the application to compromise.


Why the symmetric key is added to the message?

To answer your questions:

{K_AB}**K_B_E is prepended to the message so that the receiver has the symmetric key to decrypt the message. Because the key K_B_E is used only Bob can decrypt the symmetric key and only he can therefore read the message.

The next is the hash {h} which is encrypted/signed by the key K_A_D. I assume that K_A_D is the private key of Alice, so this is the signature of the message.

The symmetric key is created newly for each message by the sender. And the sender has to send the key for decryption purposes to the receiver. Therefore the key is prepended (asymmetrically encrypted) to each message.

Yes, GPG and OpenPGP use this scheme.

As an extension:

I can prepend multiple (asymmetrically) encrypted keys to the message so that I can send the message to multiple receivers.

If I use a pre-shared key then I have to send the message either multiple times or have to share the symmetric key with multiple persons. This would make this scheme insecure. That's the reason why I create a new symmetric key for each message.

Also note that GPG/OpenPGP do not use a CA but create a Web of Trust to authenticate all other participants.


Yes you should notify the developer. This could be regarded as quite a serious vulnerability. It's their choice whether or not they choose to listen to your advice, but at least you can rest easy knowing that you did what you could to help them improve their security for their web application.

At the end of the day they are the ones that are ultimately responsible for the security of their users, and they would be extremely foolish to ignore this obvious loophole in security.

If you choose to write an email/message to the developers, try to outline the possible consequences of inaction. This could help kickstart them into actually fixing the bug.

EDIT: I would propose they make the following changes...

Use the 'post' method when submitting web forms so that information is not displayed in the URL of the webpage like it is at the moment.
Suggest implementing SSL to add a basic level of encryption to the communication between the client and the server
Suggest using cookies to store session information and NEVER to use the information provided in a URL as a valid form of authentication. In theory when designing apps like this it would be wise to make the assumption that you CANNOT trust the end user and therefore the server side scripts/software must perform all of the necessary validation.


How to globally limit Bluetooth functionality on Android and iPhone

I have an Android phone and use it to connect to my Bluetooth headphone, Fitbit and car stereo. Normally I turn BT off when I don't use it, and most of the time I don't. So in the car, I turn it on, when I get out, I turn it off. And sometimes I forget to turn it off, and it stays on for hours.

I live in a highly populated area, and whenever I search for bluetooth devices I see ten or more. Never ever have I had a request to make a connection to my phone. Why? Because my phone is only discoverable when I search for a new device. When I do this, I look for the device that I want, connect, and that's it. When I don't see the device, it stops after a while, and the phone is not discoverable anymore.

So I don't see the problem. Other devices won't see your parents Android phone, and probably the iPhone neither. Only when they connect consciously, this can happen.

Maybe my understanding of BT is wrong, but this is how I thought it works.

Teach them how to reconnect to the speaker. They should know the name of the speaker, what to look for. If they don't see it even if they press the connect button on the speaker, they should wait and not try some random device to see if it works.

You could teach them to disable BT if they don't use it, maybe with a homescreen widget.


How to list all the permissions requested by an extension?

Menu > Settings > Extensions > Details

You can't change the permissions of an extension. It is assumed that the extension can't work properly without all the permissions, so allowing it some permissions and not others would break it partially.