IMAP credentials in WEB (browser) app - how to use securely

Based on the comments following the question:
You might want to consider encrypting the IMAP credentials on the client-side (in-browser, using the javascript web crypto api), using an encryption key generated client-side, then storing the encrypted credentials on the server.  This way, the server stores only the encrypted credentials, not the plaintext credentials; and the key for decrypting the credentials never leaves the browser.
As for storing the key for decrypting the credentials - see https://crypto.stackexchange.com/questions/35530/where-and-how-to-store-private-keys-in-web-applications-for-private-messaging-wi/52488#52488 for a solution for storing the key securely in the browser's indexedDB storage.
When it comes time to login to the IMAP server from the client, the client simply fetches the encrypted IMAP credentials from the server, and retrieves the key from the browser's IndexedDB storage, and uses the key to decrypt the credentials.


Can websites uniquely identify users by the sim card used to access the website?

Not that I am aware of.

Websites receive the information the web browser provide
The web browser of the phone devices is an app that has not the
permission to get the SIM data of the mobile device (unless it was an
malicious app)
Information of the device apart from cookies does include the User
Agent, but that string of information that not include that kind of
information.
You can not relay on IP addresses, your phone provider may use
DHCP/nat and the phone could use a different phone provider network
(roaming)

I would suggest using client side certificates, when the phone is changed remove the certificate and when user is no longer trusted revoke it.


network icon on lock screen, group policy

This generally depends on how many networks will be available in that open space design, and if they're open to anyone or protected.

As you mentioned that it is a laptop, is it going to be taken outside of the office? If so, it might make it difficult to log back into unless you're using cached credentials (if it's connected to a DC).

I would recommend user education over locking everything down - advise users that unless they're using a VPN, then any traffic going over a network that isn't yours specifically is open to being intercepted.

In short: I wouldn't, but it entirely depends on if these laptops are being taken out of the office, and if there are non-work networks that are open and available, and if education for security isn't being done in your workplace.


Personally identifiable information in query parameter for Tomcat REST service

As pointed out by Jonah B, it is usually impossible to keep all the "request line" components clean.

There is a much safer technique : do not use the PII in the request, but instead use a mapped value for it.

So instead of /customers?email=foo@bar.com you would, for example, have /customers?email=a4kl3delmze, where a4kl3delmze is randomly generated by the server upon creation.
Using a value like the hash of the email could work as well.

The point being : the parameter value is mapped to the email in the database, so you can still execute your biz-logic but you don't transfer the email string value with your requests


Hardware security key with locked down usb slots

Yes, it is possible. It will reduce security, but may still be good enough.

U2F devices appear as a HID device. That's a USB class for keyboards and mice. USB storage devices appear as USB storage devices.

You can disable one class in your OS, e.g. disable USB storage (and UAS), but allow HID.


NAC(Network Access Control) solution for Domain

May be you can use Group Policy or write a Start Up script.
PS: I assume you have Sys Admin level knowledge of Active Directory and basic scripting.


Why doesn't changing the PIN affect recorded data on magnetic card?

In the past they may have encoded the PIN on the card, however hopefully (as your test indicates) they have stopped. It looks like the article that you cite is from 2009, which is rather out of date.

As to why they should not encode the PIN onto the card take a look at the NIST Special Publication 800-63-2, the Electronic Authentication Guideline. In the case of Multi-Factor authentication it should consist of a combination of "Something you know, something you have and something you are". For a card and PIN system you have something (the card) and know something (the PIN). If you encode the PIN onto the card then you only have something, which is single factor authentication and is not as secure.

If you are interested in the security of PINs in credit cards you can take a look at: https://www.pcisecuritystandards.org/documents/PCI_PIN_Security_Requirements.pdf.
This is the PCI requirements for securing PINS.

As for the differences in the Discretionary Data these may come from several sources. From ISO/IEC 7813 the maximum record length of track 1 and 2 are different. The DD is used to fill the balance of characters.

For Discretionary Data the implementation is left up to the issuing company. As to what it might contain you may be able to find out by looking at the documentation from the issuing company (I rather doubt you will find anything but stranger things have happened). It may just be random padding to reach the proper length or it could contain additional data. See https://stackoverflow.com/questions/12239855/discretionary-data-from-magnetic-strip-credit-card-how-to-parse.


What are some examples of managed language exploits and where can I learn more?

It's really important to keep in mind, that memory vulnerabilities are from the only issues out there.

I've found that it's the logic errors, which really bring a program to its knees. Several have lead me to successful DDoS or RCE. These occur in all languages, human error can easily and frequently be exploited.

Here is a list of some, in no particular order:

Improper input validation

Real-World-Example: Injection. Being part of the OWASP Top 10, it can be found anywhere, and in any language. Especially SQL injection and XSS stand out.

Uncatched exceptions

Real-World-Example: These more often that not lead to a DDoS. I once looked at a program using threads and locks. Too bad that I could reliably trigger an exception state just after the lock was acquired. Ouch.

Use of insecure functions

Real-World-Example: Many programming languages (especially scripted ones) offer some sort of real-time eval. The use of these is bad practices.
You know what else is bad practice? Rushing out an unfinished prototype as the actual product. Happens more often then you'd think. I know that these kind of relate to input validation, however it does not always need user input specifically to exploit these.

Pro-Tipp: My scripts grep for these functions before any assessment takes place. (Source known, obviously)

Dev- vs. Production Environment

Real-World-Example: A program which used sockets. In their development environment, each machine had 'unlimited' amount of available sockets.
The computers where the software was eventually deployed on didn't.
Their server could easily be crashed, and it was a critical piece of infrastructure as well.

Developer Misunderstanding or Lazyness

Real-World-Example: This one is my favorite by far! I once looked at web server, self-built in Python.
In Python, the inbuilt HTTP-Handler has a 'do_METHOD' function for every HTTP-method. If you want your own handler, you subclass it and overwrite these functions, which is exactly what they did. Now they had one function which was called 'do_WORK', that had nothing to do with serving HTTP at all.
Python (for forward-compatibility reasons, I can only assume) calls these functions by string-matching them. Which means that Python would actually try to call whatever function with the name of 'do_METHOD' (where method is the method stated by an HTTP-Client/Request) would be available. HTTP-method 'WORK' wasn't a thing...Until then. Therefore I could now call 'do_WORK' early and trigger a race condition. Beautiful.

These are just a few, but always remember: Computers do not make mistakes, humans do.


Some places do, but most do not from the viewpoint that they are only concerned about who is getting into the place.

Places I've worked where authenticating those leaving was the norm included:

A manufacturing facility, who was also checking bags and pockets to detect if you were trying to steal product. Who got checked was randomly determined by the system. This made it so that you could not collaborate with guards to smuggle out loot.
A coal mine, where knowing who was still inside the mine during fires/emergencies was essential to knowing who still needs to be rescued. A side effect of this was that it made clocking in/out for friends impossible.
One company was concerned about people leaving a swipe card on top of the reader, so before a card could be used to re-enter the place, it had to be used to swipe out.

One place that used swipe cards for leaving was a variation of time clock for employees. Some were 2-swipe employees ("in" in the morning, and "out" when leaving at night), and some were 4-swipe employees (in addition to "in" in the morning and "out" at night, you were expected to swipe in and out for lunch). The 2-swipe folks were expected to work 50 hour weeks and were paid a little more than 4-swipe employees. This company was regulated as a bank and had the side effect that the 2-swipe employees always took 2+ hour lunches.


Access LAN services through malicious web page

I think I figured it out. This potential attack is addressed with Same-origin-policy. A browser will only allow scripts to access resources from the same origin. https://en.wikipedia.org/wiki/Same-origin_policy


What exactly is the impact on security when forcing user passwords to contain a particular character?

You are basically reducing the overall entropy of your password, as one of the characters will always be known.

This effect is further amplified by the fact that most humans are predictable creatures. If you force them to place an arbitrary character somewhere in their password, there is a high chance that character will be the first or last character in the password.


Practical steps for encrypting an encryption key for data stored in MySQL

The string length of a bcrypt hash isn't compatible as an AES key because of length and illegal characters such as periods and dollar signs. How does one deal with this problem?

Base64 encoding is your friend.  Base64 encoded character are all legal characters with AES

  When it comes to decrypting Enc_KEY1, I have to first generate KEY2 from a hash (bcrypt) of the user's password... how exactly do I recreate the hash? Am I supposed to store the salt? It seems like bcrypt wants to create a random salt each time... but unless the salt is stored, there's no way to recreate the same hash... Is it bad to store the salt? What am I missing here?

Yes, you need to store the salt (and optionally pepper if you are using AES to encrypt the password hash).  Without it there is no way to re-make the hash.


What to do about vulnerability in a SaaS product I buy?

Is this attack acceptable, or at least common among large enterprise systems?

No, this is absolutely not acceptable at all. And I do hope it is not common.

  I believe wrapping user-generated content in an iframe with the sandbox attribute would block this attack (provided admins use up-to-date browsers), by using CORS to prevent requests to the REST API. Is this safe?

In theory a completely sandboxed iframe would help. But as you point out, support for the sandbox attribute is not perfect. It only takes one administrator with an old browser for you to be owned.

  Is it otherwise possible to make user-uploaded javascript safe?

You could take a look at how sites like JS Fiddle solves this problem. They echo the user generated content back from a different domain, thereby levereging the browsers SOP for protection.

But if you are buying SaaS, it should not be your role to fix this.

  If the vendor refuses to fix it, what are my next moves? Is public disclosure recommended, given that it is fairly easy to exploit once it is known about?

In your role as a customer, I would recommend you get the lawyers on the case. If your contract is any good, the company delivering the system is in breach of it. If you are paying for a product with different permission levels, you should make then deliver one. Currently, they are not.

In your role as a researcher who found a security vulnerability, I would recommend responsible disclosure. Among other things, you should give the vendor a clear deadline before you disclose.

  I admit I'm a bit hazy on the difference between csrf and xss.

As others have pointed out, what you describe is stored XSS and not CSRF.


How to maintain security and trust with a PGP keypair for a team or group of people?

The setup you described is not ideal. It would be better to implement a certificate authority and setup everyone with their own private-public keypairs. There are schemes where you would then grant access to a shared resource using ACLs at the application level or by having a symmetric key which is used for access and encrypted with each person's public key. You would then change these shared keys for any affected resource when someone leaves.

  For a realistic scenario, let's talk explicitly about a
  security@example.com mailbox with PGP key "Example Inc. Security Team"
   (0xAAF00F00) where Bob, Alice, and Charlie (the
  team) have access to the mailbox, and PGP public/private keypair.

In your scenario, the shared keypair is not relevant. Even if they have their own keys, once its decrypted they have it. If you have an encrypted document and you have the key, and you leave with both it would not matter either because unlike with a paper document in a filing cabinet its trivial to make copies. If I leave the company, why do I still have access to the mailserver? If I do not have access and I still have the decryption key, I would have to break in and presumably defeat some other layers of security to even gain access to first decrypt it.

I would not recommend sharing the mailbox like this in general because there would be no accountability for who sent out an email or who read an email because they are technically sharing the identity. Better to have the message fed into a system with RBAC. Maybe you would them implement an HSM solution combined with certs/keys for access to the system and the decryption is owned by the system not the users.

Security needs to be applied in layers. Do not permit the thumb drives, make them log in through Citrix with all printing and copy and paste disabled, make it so the only way to get a copy of the data is by taking a picture (you could physically prohibit cell phones and cameras). The concern here is really the ability to copy digital data. You could implement some DRM based solutions potentially to address this as well, but DRM can be defeated and it doesn't prevent copying or screen caping.


I think you may be getting confused with server-side password hashing.  Server-side password hashing is essential for any system worth its salt (pun intended), to prevent users' passwords from being leaked in the event that the user database is compromised.  But, it only works because the server just needs to verify when a client provides a correct password; the server never needs to provide the password. IOT devices, on the other hand, are usually clients. So, they need to provide the password to authenticate with the server. Therefore, IOT devices need the actual password, not the hash of the password.
See https security - should password be hashed server-side or client-side? for more information on common misunderstandings about client-side password hashing.


Deleted commit still visible from GitLab web interface, exposing sensitive data

I'm not very familiar with Gitlab or what BFG repo cleaner does. But it is always a good idea to rotate your passwords when they have been exposed in public. If it's a public repository, there's no way to reliably know if the old git commits have been checked out by someone. That said, lodge a support request with GitLab too, just in case.


How can I tell what cipher was used by python-gnupg?

file only looks for some magic bytes to determine the file type, but does not fully parse the OpenPGP packets. You can view all encryption details by running gpg --list-packets or pgpdump (output is easier to read, but needs to be installed separately). Reading through RFC 4880, OpenPGP might help at understanding the very technical output.


How do user get access to login when passwords are stored in MD5?

MD5 is deterministic, meaning that if you hash the same input multiple times you will always get the same answer. So to see if a password provided by the client is correct, the server can just hash it again and see if the hash is the same as the stored hash.

Similarly, a MD5 dictionary works because someone has hashed common passwords and stored the results. If your hash is in the list, you can just look it up and see what input it corresponds to.

I think your central misunderstanding is that MD5 could give different results for the same input. It does not.

Also note that MD5 is not a safe algorithm to use for password storage. For how to do password hashing right, see this question.


Did DARPA's Cyber Grand Challenge winner actually discover previously unknown vulnerabilities?

The DARPA test bed, CGC (Cyber Grand Challenge), was a modified Linux platfrom (DECREE). Its binaries (the compiled machined code for the system) contained only 7 system calls (e.g., terminate, receive, fdwait, allocate, etc.). Within the system code as a whole were DARPA crafted Challenge Binaries (CB) with one or more vulnerabilities to fuzzing, i.e., vulnerable to input of some character.

One of the early examples of fuzz testing was Steve Capps' "Monkey" to test for bugs in MacPaint by feeding random events to the code. "Monkey" alludes to "a thousand monkeys at a thousand typewriters will eventually type out the entire works of Shakespeare," i.e., if you send enough random or protocol crafted input to a program eventually you will find a way to crash it. Fuzz testing will typically not find security threats that do not cause program crashes, e.g., spyware, many viruses, worms, Trojans, and keyloggers. However, it will find exploits based on unexpected program input (or code errors related to program input), so may have been able to find the Heartbleed bug, which was a bug caused by improper input validation in the implementation of the TLS (Transport Layer Security) protocol (in OpenSSL).

The winning team, Mayhem, used a symbolic executor (Mayhem) in conjunction with a directed fuzzer (Murphy). A symbolic executor is familiar to those of you having worked with symbolic debuggers in integrated development environments, i.e., it is basically an interpretor that steps through the code and allows the assignment and tracking of symbolic values for inputs at various portions of the executing code. In other words, the Mayhem team was able to statically analyze portions of the CBs (Challenge Binaries) with Mayhem to detect (or analyze Murphy's suggestions) code vulnerabilities. This was a requirement of the DARPA challenge, i.e., to find a vulnerability and demonstrate it, i.e., POV (Proof of Vulnerability). Unfortunately, symbolic execution doesn't scale very well since the number of paths in a program grows exponentially and can go infinite with unbounded loop iterations, so heuristics or path-finding (enter Murphy fuzzer) to partially solve this path explosion problem (computing methods like parallelizing help also).

The DARPA CGC (the challenge) required the teams to not only locate vulnerabilities in the CBs (challenge binaries), but to document those with a POV (proof of vulnerability) and repair the vulnerability with a Repair Binary patch (RB). That patch would be tested for performance, both correct operation without the vulnerability as well as literal performance impact on the relevant code (execution time). This is all fairly amazing considering that a human was not allowed to contribute to any of what I just described.

You can read more at the blog of the winning Mayhem team here Unleashing Mayhem!, obtain DARPAs Grand Challenge rules and other documents here Darpa Grand Challenge related documents, read about fuzzing at Fuzz Testing and symbolic execution here Symbolic Execution.


Does your ISP know what type of phone/computer you're using?

Depends on the device and if you have taken any steps to hide it. Most devices by default put a lot of identifying information in the User-Agent header on outgoing HTTP/S requests. For HTTP requests these will be visible to anyone with wire access. For example for Android from here -

Mozilla/5.0 (Linux; U; Android 4.0.3; ko-kr; LG-L160L Build/IML74K) AppleWebkit/534.30 (KHTML, like Gecko) Version/4.0 Mobile Safari/534.30
Mozilla/5.0 (Linux; U; Android 4.0.3; de-ch; HTC Sensation Build/IML74K) AppleWebKit/534.30 (KHTML, like Gecko) Version/4.0 Mobile Safari/534.30

And for iPhones -

Mozilla/5.0 (iPhone; CPU iPhone OS 6_1_3 like Mac OS X) AppleWebKit/536.26 (KHTML, like Gecko) Version/6.0 Mobile/10B329 Safari/8536.25

Mobile carriers/providers meanwhile have access to your IMEI which uniquely identifies your device.
*As @Anders points out there are also service fingerprinting techniques. Any connection to a manufacturer related applications/service could be an indicator. As could profiling of data patterns (a simple approach would be fingerprinting device update files). I initially leaned towards user-agents because the original question asked about ISP's / this approach can be used no matter how the device is connected (i.e. IMEI is only visible to your carrier unless they forward it on. User-Agent would be visible on non-encrypted requests from any internet connection - WiFi, ADSL etc).


Sending access tokens from server to client best practice

You cannot do this, and I will explain why. I am assuming we are talking about OAUTH2, which states clearly what you can and cannot do with a token. OAUTH2 divides clients into five categories:

Confidential
Public
web-Application
Browser-Application (Client side)
Native-Application (Client side)

Each of these use their own authorization methods to obtain the access key (grant types). Before you can query an authorization token at all, you must have registered the application with Google and got an client id (and secret) in return.

Getting to the point; when you registered the client you chose a client category, and I am guessing webapplication (client credential) based on you topic. However, once chosen a type, you promise to use any tokens for that client type only. If you were to send the access token from the server to the client, you break that promise.

OAUTH2 divides client types for a reason, primarily based on security and the ability to keep tokens secret for some time. If you want to store the access token in the client side, then switch to Implicit. Obviously, you cannot use the key on the server for the very same purpose.

The image below demonstrates the differences.


How to generate the most secure private key?

Using AES and 4096 bit RSA would certainly help. At least openssl uses 3 key triple DES but that means both the triple DES and the RSA private key are stuck at a security strength of 112 bits. See https://keylength.com for information on key strengths. 112 bit is just enough but a bit too close for comfort; I'd sleep better with 128 bit security.

openssl genrsa -aes128 -out mykey.key 4096

Note that 3DES is used in CBC mode, offering confidentiality only. That means that an adversary could change the value of your private key without you knowing it. If that's OK depends on your situation - an attacker may not be able to reach your private key or maybe you're just interested in keeping the private key / messages confidential.

You might consider storing the keys in a PKCS#12 container instead, which offers just a bit more security. You'd need a certificate with the public key to do so though. Unfortunately the genrsa command doesn't seem to allow any authenticated mode of encryption such as AES-GCM. Possibly you could place a signature over the generated private key (in case you have a different private key used for code signing around). Or you could store a hash over the private key file somewhere safe and compare before using it.

The weakest point of password encryption is always the password. Older command line openssl, before 1.0.0, uses a pretty weak password based key derivation function (with a single iteration count). Newer openssl fortunately uses PBKDF2 with a - still low but better - iteration count of 2048 (see the comment of Dave below). You may increase this count using -iter N command line option. More importantly, you can avoid issues by generating a very strong password, storing the strong password in a password manager of some sorts. Chances are that you won't be able to remember a really strong password (or the password may simply be not as strong as you assume).

Above advice can be used to generate a more secure private key; there is no such thing as a most secure private key. If there would be such a thing, then I would doubt that you could use (software only) OpenSSL command line to generate it.


Is using a third party browser in iOS more secure than Safari?

Basically not, since all 3rd party browsers on iOS use the webkit engine.

A simple way to demonstrate that is with CSS stylesheets, any browser specific attributes such as -moz won't be rendered on the Firefox iOs app. Only the non vendor-specific css or webkit attributes.

Therefore all potential vulnerabilities webkit has, apply to all browsers inside the iOs ecosystem.


What evidence is there that SpiderOak is significantly different from Lavabit?

You can prove this to yourself by watching the traffic that leaves your computer to go to SpiderOak.  That data should be encrypted by a key that only you control.  Even if they made a mistake, your data is encrypted before it leaves with a widely tested algorithm.  You can verify that your data is encrypted by that algorithm.

In addition, SpiderOak hired an outside firm to audit their recent release: crypton.io
https://blog.spideroak.com/tag/audit

Finally, the EFF seems to agree with the ZeroKnowledge claim:
https://blog.spideroak.com/20131122173304-spideroak-encrypts-best-as-per-effs-crypto-survey-report

Zero Knowledge in this usage isn't really a mathematical anything.  It just means that they only store an encrypted mass of data and don't know your key.


How to prevent the following clickjacking attack?

The only way to prevent clickjacking on a version of IE too old to support X-Frame-Options is to make the page dependent on JavaScript, so that it breaks when run with security="restricted". For example:

       ...

       This site cannot be used in a frame or with JavaScript disabled.

Obviously this has strongly negative accessibility implications. If the site in question already doesn't work without JS it might be acceptable, but it isn't usually worth it.

(It also demonstrates the tactic of making your page unusable instead of trying to redirect the top page as in the 'very poor' framebuster. Indeed, the redirect option cannot be made secure.)

I'm not sure what your last comment is referring to - X-Frame-Options doesn't prevent file uploads, but it works fine to protect against framing from any site (third- or first-party), the only problem with it is the lack of support in old versions of IE.


Why does it not cause a buffer overflow when a large string is validated for length?

I code exclusively in high-level languages where buffer overflow's are not an issue, so I apologize for not having a code example for you.

Example; when writing a string to memory which was received over the network: (untrustable data)

A space of memory is allocated to store the incoming string.
A string is read from the network in chunks. In many cases the length is not known.
The string is written at the starting position of the earlier allocation. Additional data is appended at that point until the desired delimiter is found. (i.e. \n in an HTTP request)

If the string is too long, then the data overflows beyond the allocated space, possibly overwriting additional memory allocated for another purpose. This often produces a safe crash; but in specific circumstances such attacks can have dire consequences, especially if the injected string will be interpreted as executable code.
A secure application will allocate a larger buffer as needed. This occurs automatically in a high-level language.
Alternatively you could truncate or reject data beyond the maximum length.

Additional examples can be found on Wikipedia

There are also read-only attacks that be performed on insecure programs:

If a buffer is allocated, but the write is incomplete, (i.e. string received is shorter than expected length) then there will be random data leftover in that buffer. If the buffer is later accessible by the attacker, then random memory can be stolen.

Most high-level languages will zero-out allocated buffers, but this is less efficient, so some languages provide an option (or default) to skip the zero-out step.
Integer overflow vulnerabilities could be used to bypass length checks later in the program. If a maliciously edited integer value is used to read memory locations or to set the length limit of a read operation, then random memory can be stolen.

Integer overflow would occur if math is performed before validation. For example, if(requestedDataLength + someModifier < limit) should be changed to if(requestedDataLength < limit - someModifier).

Integer overflow can be used for attacks that are unrelated to buffer allocation. Many high-level languages are be affected by integer overflow, but this is less common.

The consequences may vary but at the worst it could result in theft of sensitive access credentials or sensitive data.

In a high-level language, buffer allocation and length handling is automatic, and these vulnerabilities normally cannot arise.


Is it possible to search HTTPS messages using homomorphic encryption?

HTTPS works over TLS/SSL. The TLS/SSL uses usually RSA + AES. For RSA as well as for AES it is impossible to restore the pre-image, simply said, based on the encrypted message it is impossible to get any information about the contents of the original message, of course except of rough message size.
The paper you refer suggests a new encryption scheme. You could consider using it, if you had plain / unencrypted messages. But the messages are already encrypted with RSA + AES and there is no way to know the original message.
The same with homomorphic encryption. You could consider using it, if the plain messages were encrypted by some homomorphic scheme. But the traffic is already encrypted with RSA + AES and there is no way to know the original message.


Why keep track of user password changes in web application?

I think I am missing a point on why sites need to keep track of user password changes.

No website HAS to keep tracks of user password changes. It's just that some do.
Keeping tracks of password changes allow several things :

Remind the user that he change his password.
This is usefull if the password has been changed by someone else. If it's not you then you know you have to change it again right away ! (You don't have to be hacked personnally to have your password compromised. All you need is password reuse and a hacked service.)
Remind the user that he already has used a password. This ensure that you are changing your password for a real new one and not using a password that you might have changed because it was compromised.
Remind the user that it might be time to change his password.


How to find files accessible on external network?

You could try with ENT (Essential NetTools) or a similar Utility to do a shared-resource scan from outside your Network and see what it finds.


The whole point of GDPR is that the data subject can know what data is collected and what data is processed in order to provide services. So you have to give them all the data you have on the data subject. Why only give them back the data they gave you?

The wording on portability is about using a common data standard and not a proprietary data format that would impossible to use in any other system. You need to export the data in some commonly parseable standard (XML, CSV, SQL, etc.).


No, this is definitely a scanner trying various URLs on the server to see which URL it can find.

For example, if it finds "/phpmyadmin/scripts/setup.php" it knows you have phpmyadmin installed, and where it's installed.  The attacker can then find the version, and run a known exploit to get access.

As for how they found it, it could be several ways:

Amazon has a certain IP block assigned for their use.  It's publicly known, so you could just hit each IP address in that block.
You could fuzz urls, using a dictionary of words and a dictionary of TLDs.
Google will have indexed the site, as Google is notified of all domain registrations (as per it's status as a registrar (See here for an illustration of the trouble it cas cause)


If I understand correctly, it sounds like you logged in, then you navigated to the change-password page, then the site populated the disabled password input box with your existing password, then you were able to recover your existing password from this disabled password input box.  If that's the case, then the site is storing your plain-text password - either from the time when you logged in, or permanently in their user database.  Either way, it's bad.
With regard to using a hash of the password as the key to encrypt the password - see https://crypto.stackexchange.com/questions/51820/is-it-safe-to-use-the-hash-of-the-data-as-the-key-to-encrypt-them for some interesting thoughts around this method.  Notwithstanding, I don't think this is what is at play here, because it just becomes a cyclical problem - the site would not be able to populate the disabled password input box with the password encrypted in this manner, without knowing the password.


Server providing two different SSL certificates

My guess is that this site is using Server Name Indication (SNI). In this case the served certificates depends on the hostname specified in the SNI extension and will often differ if no SNI extension is used. I.e. it will be some completely different default certificate or it will be some old certificate because they only replaced the certificate used for SNI when renewing the certificate.

Modern browsers all use SNI for years while outside the browsers the support is mixed. Support for SNI was added to Python with version 2.7.9 in 12/2014. It might be that you are running an older version of Python or that you are using a lower level access to the SSL connection where you have to explicitly set the SNI extension yourself.

In theory one could also send different certificates depending on the capabilities of the client, i.e. certificates signed with SHA-256 for a TLS 1.2 client but a SHA-1 certificate for a TLS 1.0 client. In practice most TLS stacks don't offer this kind of behavior or make it hard to use and thus servers don't implement such a feature. Thus I guess that your problem is related to SNI.


How to sign a text in a way, so it can not be altered or split in parts unacknowledged

Firstly, Make your work a notarized document. Establish a legal contract with the third party to publish your work without alteration. As far as I know, in most countries, without a contract you will remain the sole owner of your work.

Secondly, publish the hash of your document as you suggested.

When the third party publish an altered version of your document, they will break the contract and you will not be bound by it anymore. Then, you will be able to prove ownership of the original by publishing it and pointing to the hash, and in front of a court you will be able to produce the contract and the notarized document.

I'm not a lawyer and I do not know the law where you live, so you might want to seek a proper legal counsel. Especially about agreeing to a contract that covers yourself in case of a dispute.


Is there a way when using WIFI to know the specific users computer ids?

By computer ID, do you mean name/NETBIOS name?  This could be known, along with the MAC, a couple of different ways:

Using the AP software/webUI itself. The management console may already provide this information to you.
If you run switches that are fully manageable, you can track down what MAC addresses are connected to the port from which your AP is plugged into.
Third-party tools and software could also provide this information for hosts that are connected to your network.

Anyone connected to your AP would be able to run any number of networking tools to try and find information about the devices on the network. Once someone is connected to your network, they are able to then run attacks and reconnaissance against your network. So a knowledgable user could gain a substantial amount of data or do a lot of damage if your network is poorly designed or secured.


What protections exist on operating system clipboards?

What protections exist if any to say a malicious website in another tab copying clipboard content?

This is handled at the web browser level. There is no API by which a webpage can read the clipboard without explicit user interaction *. It would only be possible with a browser exploit, in which case you would probably have bigger problems.

* Obsolete IE versions had an option where this could be enabled, but it was not enabled by default.


Do absolutely nothing else with or at the site.

Don't make things worse.

In many jurisdictions you may have already crossed the line into not so legal. (You should get legal advice from a computer crime specialist lawyer in your jurisdiction about what you've done, by the way.)

You have notified the site owner, which we commend you for, and your lawyer will yell at you for. If they ignore it, that's down to them.

Lastly, if you've used that password anywhere else, change it there immediately.


Why does my compiler warn me about gets but not about scanf?

In general, scanf is not considered a safe function. It can be used safely or unsafely. In this case, your compiler is not issuing a warning since it does not have a lint that for an unbounded "%s" format string - i.e. it does not know that you are using it unsafely. On the other hand, it is hardly possible to use gets safely, as there is no way to provide a buffer length, so your compiler can with high confidence determine that you should not be using it.
To use scanf safely in your example, you'd need to provide the length in the format string, like so:
char buf[10];
scanf("%9s", buf);

The buffer needs to be one byte larger than the length specifier in the format string to accomodate for the terminating NUL byte.


Password salting vs. length extension attacks

No, they are not applicable at all.
Two cases;

Online password try with the application interface: The attacker has no control to execute a length extension attack.

The attackers have a write access to the server:
To be able to execute a length extension attack on the passwords, you need to know the original passwords, too.  If a password is hashed then actually it is stored as
h(salt||pwd||pad1)
With the length extension attack, it will be
h(salt||pwd||pad1||extension||pad2)
Therefore, they need to know the original, too. Hey wait there, if they can access to write then they can modify it with h(salt||password that that know)

Length extension attacks work when the attacker can modify the message that is going to be sent or during the transmission. An example is the Flicker API
Final note: For passwords, you need a memory-hard password hashing with calculation timing control ( possibly with iteration). The current trend is to use Argon2.


Automatic Password Reset - is it a good idea?

Theres no problem with this, but a better solution in your case is to use a random "hardware PIN" used only when communicating with the "stupid hardware", that is stored inside account, possibly encrypted with a hash of the user's password. (and to verify password at login, use hash(hash()) of password). Thus you can use a normal password for the web frontend, and thus does not need to enforce hard try limits. (instead you can enforce a timed try limit)


Use D Parameter Of Private Key as HMAC Secret for JWT in a Load Balanced Environment

This is one of those cases, where I don't believe there is any known way to exploit this. So you could argue this is secure. But the problem is, this is not something that is proven secure and it is not what these functions were designed for. Therefore it is likely there may be a way to exploit this. And if one is ever found, it could reveal your RSA key, which is the most important key you have as a web server. That is why this is NOT CONSIDERED SECURE, even if there may not be a way to exploit it. Don't do this, there are better ways.

Also, it does open a new way for the RSA key to be brute-forced, which may or may not be faster then computing it from the public key.


Indicator of Compromise - Mozilla Firefox - Malware Redirect

I don't think that it has anything to do with malware, from what I see is just another tricky way of getting traffic on the website.

Another tricky way that leads from this website ww9.fromsubjectreceivedsizecategories.com is mistyped domains, which are owned by scammers.

REAL: establishedmen.com
FAKE (mistyped): establishedmem.com

Here is a nice article about it: https://nakedsecurity.sophos.com/typosquatting/


Worst case scenario for compromised private key in server certificate?

Yes, seems right, unless someone get to your server and reach the private key eventually. Then he may be able to decrypt what cert encrypts.
Good practice is to rotate the passphrase once a while - so change it ASAP.
If you don't know whether the stack was compromised, renew the key and cert completely and scan system for indications of compromise.


Sending messages using OTR & and GPG -- is it detectable?

The simple answer is yes - your ISP can very easily see that you are sending an encrypted message. In many countries this is not an issue for two reasons:

most of the major webmail providers now use SSL so everything is encrypted
there would be too much data for the ISP to sift through it all, so they target specific threats (if you are one of those threats then sorry, your data is theirs...)

I understand that you feel like the ISP could target you, or that using encryption will make you stand out from the crowd, so there are ways to make encryption less obvious - however they are more effort:

ASCII Armouring as carried out by GPG leaves a header and footer describing the encryption used, but you could remove this if you wanted. The problem is that the data sent still looks like a large block of random data...which is still probably suspicious to your ISP
Translate every word you want to send into another word (using a one time pad if necessary) - then your message will be made of words, so probably won't trigger any filter looking for encryption (however a human interceptor reading it might get suspicious)

Your activity should be based around your threat model:

Are you a target for your ISP to waste effort on?
If not, would using encryption make you stand out from the crowd enough that you become a target?
etc


Securely installing software in a hostile environment

Is trusting the package manager's signature enough?

No. There have been numerous vulnerabilities for those in the past. Of course it also depends on the adversary. But when you assume that he can do mitm then he probably is well equipped and can do some other attacks too.
Just because it has been signed somehow it does not automatically make it bullet prove. In the end it is software checking other software. (Most) Software has bugs ... Maybe someone got the signing key and can now sign anything they want ...
iirc there have been bugs in the update mechanism for the BIOS in case of big companies with big budgets too (Intel)
Originally apt did not use https and there even was a website explaining specifically why. After a new attack was published which would have been prevented by https the owner of the website changed its content. Sadly the original site does not exist anymore.
https://www.reddit.com/r/linux/comments/aidxwa/why_does_apt_not_use_https/
When you google for packet manager security + linux you should find some more or less recent publications and potential attacks.
Using apt with https makes it certainly harder. The question is if it is hard enough. Against a nation state which could fake certs, redirect traffic or has access to the server itself it wont help.
You could take a look at the certs send by the server or watch the system behavior. Ideally, you would still have another secure(TM) system where you could cross check the results.


Prevent apps from having full access to user files

Applications should not have access to data of other applications or to user's private data unless user allows them. Isn't this an obvious need?

No, this is not obvious. Traditionally software installed on the system was considered trusted, i.e. it was not expected that users just go to the internet and download some possible harmful application. It was also not expected that users run insecure software which might interact badly with some remote site and thus give a remote attacker access to local data.

Therefore the security boundary in UNIX (and other OS) is by design the user and not the application. In fact, there is not even a concept of an application as you would like to have - complex applications (like Office) are actually made up of several binaries, libraries, config files etc.

I think that this design is still valid in many use cases, i.e. cases where the systems does not get changed much in the first place or where only trusted software gets installed. But there are also now cases where users actually install software from potentially untrusted sources or install potentially insecure software and expect this software to not do much harm. In these cases the original paradigm of using only the user as a security boundary is not sufficient.

There are OS designed with a different paradigm, i.e. where it is common that users download possible malicious application from the internet and want to restrict access to private data. For example in Android each application is essentially installed as its own user and thus the user boundary is used to restrict access to data generated by another application (this is slightly simplified on how it works).

Thus, if you consider applications untrusted by default you might better run an OS which is designed around this paradigm from start instead of trying to modify an OS which was designed with a different paradigm. As you realized yourself - any attempts to apply the concepts of untrusted applications to a system designed around trusted applications are clumsy and inconvenient to use.


By surface area, Grossman is referring to the principle that the probability of successful attack increases as more of a system's security boundary is identified. 1

In the question, the surface penetration for the an attacker to run JavaScript from JSON (whichhttp://blog.watchfire.com/wfblog/2011/10/json-based-xss-exploitation.html may arrive at the browser through an asynchronous RESTful GET or POST) may require two breach points.

The ability to inject JavaScript into the RESTful JSON stream
The ability to transfer execution to one of the objects instantiated during parsing

Depending on the conditions prior to the attack 2, one or both of those mechanisms may already be in place, therefore not requiring that particular breach. 3

The direct answer to the question is that the various documented XSS attacks can be used to accomplish either or both of those breaches.  Which ones that might be used will depend on the details of the surface Grossman mentions.

There is an example in the comment from @rápli-andrás, and here is a good overview with more code examples.

[1] Once a breach occurs, if there is no further security surface, the attack is complete.  Otherwise it is partial, which still may facilitate the attacker's objectives.

[2] Conditions include the design of the system and its current execution state in the browser and server.

[3] This may have contributed to the vulnerability with the Google Reader.


How to protect devices that are reliant on Bitlocker and a password without TPM?

If a device is stolen does the use of Bitlocker without TPM offer a degraded level of security comparatively?

Yes, TPM are used to further protect the master key. Without it, bitlocker security is certainly degraded. Because of the secretive nature of Microsoft, it is impossible to say how much, but it would be recommendable not to trust it.

  If yes, what options are there to protect the data (assume that internet connectivity isn't always possible so access to data from services such as DropBox isn't always feasible. Staff often work on local copies of data)

Dropbox would not solve your issue anyway. You may want to look for other full disk encryption solutions. I personally use VeraCrypt, but other solutions are available as well. VeraCrypt uses a slow KDF instead of TPM, so as long as you use strong passwords, it will protect the data fine. (Note that if the computer is turned on, there are theoretical attacks such as cold-boot attacks, but these are very hard to pull off. If the computer is logged-in as well, then obviously no amount of encryption will help)

  If users remain logged into online services, are these at risk of being compromised should a device be stolen and if users do not log off?

Most online services allow you to log out from all computers. This should be done if a device is stolen. Also changing the passwords is advisable, as they may be saved in the browser or elsewhere in the computer. Though if the computer drive is encrypted, there is little risk.

  In assessing a number of these devices, i have observed that Bitlocker is often suspended and has to be re-enabled manually. Does this increase the risk of data being compromised if a threat actor were to boot the device using a LiveCD for example?

I am unsure about this. It seems to me this should not even really apply for a computer without a TPM.

  Can the device be secured further? If so how? For example, should BIOS passwords be enabled?

BIOS passwords provide little additional security. I would suggest a good FDE and strong password on boot + mediocre password for windows account. Then use [Windows Key + L] to lock the device whenever going away. The highest risk is often the laptop being snatched when unlocked, as it is by far easiest for the attackers.


What type of hashing method is used for the private key to encrypt for signing messages?

You don't use a hash function to encrypt things. You use an encryption algorithm.

You don't use an encryption algorithm to sign things. You use a signature algorithm.

The text you quote uses to traditional explanation of signatures as "encryption with a private key", which is a very confusing way of stating things, and works only for a specific signature algorithm (RSA), and in fact is wrong and does not work at all for RSA. You'd better forget it altogether.

Instead, let's see how RSA signatures work. The main signature algorithm that is called RSA follows the PKCS#1 standard, and more precisely the "old-style v1.5" method that PKCS#1 calls "RSASSA-PKCS1-v1_5". That method looks like this:

The message to sign is m (a sequence of bits).
The RSA key pair uses modulus n whose length is k bytes. For instance, if the key is said to have length "2048 bits", then this means that 22047 < n < 22048, and k = 256 (2048 bits are encoded over 256 bytes).
To sign the message m, first hash it with a hash function, e.g. SHA-256. This yields a sequence of bytes with a fixed length, 32 bytes in the case of SHA-256. Hash functions are public (no secret parameter) and deterministic (for the same input you always get the same output).
The hash value h(m) is then padded: a sequence of exactly k bytes is built as follows:

    0x00 0x01 0xFF 0xFF ... 0xFF 0x00 id h(m)

In plain words, you take one byte of value 0x00, then one byte of value 0x01, then some bytes of value 0xFF, then one byte of value 0x00, then a fixed header (id) that identifies the hash function, then the hash value. The number of 0xFF bytes is adjusted so that the total length (in bytes) is exactly k. This padding process is described in section 9.2 of PKCS#1.
The padded hash value is then converted into a big integer x by interpreting it with big-endian encoding convention. Since the padded value has length exactly k bytes (the same as n) and begins with a byte of value 0x00, it is guaranteed that x will be lower than n (numerically).
The signer uses the private key to compute a number y which is the e-th root of x modulo n, where e is the public exponent (a part of the public key). That is, y is such that:

    ye = x mod n

The private key contains some values that make that computation feasible.
The signature s is an encoding of y into a sequence of exactly k bytes, there again using big-endian convention.

To verify the signature, one decodes s into y, uses n and e to recompute x, re-encodes x into bytes, and checks that the resulting string contains a correctly padded hash value, and that the hash value matches that of the purportedly signed message m.

All of the above is deterministic, so if the signer tries to sign the same message again, with the same key, then the exact same signature will be obtained. However, note that:

If a distinct private key is used, then the signature will be different. This is expected: a signature value is specific to a given signed message and to a given signer; otherwise, it would not prove anything.
Though the old-style PKCS#1 v1.5 signature scheme explained above is deterministic, not all signature schemes have that characteristic. Even PKCS#1 includes a "new-style" signature scheme (RSASSA-PSS), that still relies on the RSA modular exponentiation, but with a different padding that includes random bytes. With PSS, the same signer using the same key to sign the same message twice will get two distinct (but equally valid) signature values.

RSA encryption is a different beast, but it is also described in PKCS#1 (in different sections; search "RSAES"). At its core, the same mathematical operation (modular exponentiation) is used for both encryption and signatures, but the padding methods differs a lot, and the padding is crucial for security. RSA signatures really are not a kind of encryption. Also, while RSA signatures and RSA encryption appear to be able to use the same kind of public/private key pairs, there are good reasons not to actually use the same key for signatures and for encryption.


How do banks determine when to ask for two factor authentication?

I know several banks use "profiling data" from previous logins in order to try to determine the identity of the user based on:

Credentials (obviously)
Secret question (not all banks use this method though)
IP address (Geo Location + time zone) and internet provider
The device(s) previously used to communicate with the bank:

a. Type of web browser, its cookies, plug-ins & add-ons

b. Screen resolution

c. Browser dimensions
Timestamps range:  Within what range a user generally logs in.

There are more factors than the above list but it is basically a risk engine that determines when two factor authentication should be triggered or not.


how to configure windows login to get OTP as password

the solution i found for this problem was to add a Credential Provider (CP) for windows to change the authentication type to OTP and then use Raduis to connect it to the OTP server or any autentication server that you want.
to be more clear what thing you need for this is the Credential provider.its conditions depends on you.
P.S : the CP i used was the PGina.


Steps after getting hit with malware or browser exploits on Xubuntu

Wiping your system and restoring from trusted media is definitely a good idea. At that point your system should be safe. However, I'd also suggest rotating your passwords on online services as well as using new passwords when you reinstall Linux. If you have ssh keys in use it wouldn't be a bad idea to rotate them as well. It may seem a little excessive but it's the only way to be sure you won't have repercussions from this later.


CSRF vulnerability in CGI/shell script web interface of hardware

CSRF can happen anytime your server services POSTs† that don't originate from a form served by your server‡.

Not using cookies for authorization doesn't mean CSRF can't happen.  An embedded iframe can still POST to any guessable URL with guessable parameters.  A custom user-agent can still send guessable headers.

  It is one time authentication through lighttpd ldap authentication.

I don't understand the details of this authentication method, but one-time usually solves the problem with CSRF.  You won't be vulnerable to CSRF if

your reboot service always prompts the user to enter their credentials to do a reboot, then it is not by itself idempotent
the reboot service is only requested from a form with an unguessable action (e.g. one with an embedded secret or embedded credentials) from a page that checks LDAP
the reboot service only works when it has an unguessable header that is set by a page that checks LDAP then CSRF isn't a problem.
the reboot service is only reachable by an unguessable URL

† - more generally, any unsafe/side-effecting operation
‡ - more generally, not from code trusted by the origin that services the request


Do readers for the "Mifare DESFire EV1" smartcard really need to know the card's secret key in order to authenticate the card?

Edited:
OK. As there is request for "short answer" here is "executive summary" here it is:

Question: “So all the reading devices must know the secret key, too. But there can be many readers from many vendors (e.g. coffee machines, small USB readers at cash registers, access control panels…), do all of them really have the secret key? Is there a standard on how the key has to be stored?”

Answer: “Yes. Apart from remote/server initiated communication with DESFire card, all readers has to know secret keys too.
And Yes – there is standard on how the key has to be stored – use of Secure Access Module – MIFARE SAM (currently AV2 model).

All content below you can forget if not interested ;)

There are basically two families of MIFARE cards: MIFARE Classic and DESFire (and similar derivatives).
Additionally there is MIFARE Plus, which has been targeted initially at MIFARE Classic markets (which it fully supports, if configured to do so), has two additional security modes of operation, which add more security to MIFARE Classic infrastructures up to a level similar to DESFire.

There are many authentication protocols used among those MIFARE families, some are quite similar but sometimes differ in small details, which may lead to reading infrastructures NOT being capable of handling another protocol even if they look very similar at first…

What is more important to your question about DESFire EV1: the basic approach for reader side security is the usage of so called "Secure Access Modules" (SAM), which are specialized smart cards, providing security related functionality to the readers/terminals. The SAM holds all keys and also has an engine to conduct security protocols, used within the secure communication between the card an the reader. This is the anchor of reader security in terms of DESFire EV1 usage. The keys might me also be derived individually for each card, so they do NOT use the same key for all the of card's authentication and encryption protocols. The key in a SAM module can be securely uploaded to the SAM in field by using additional encrypted protocols from the host OR by a batch offline upload (from an USB stick for example).

Some RSA based protocols are also supported for signing/verification to ensure some actions are authenticated without the use of shared keys protocols.

The SAM is cleverly planned and pretty solid in terms of security, so putting such a SAM module in a vending machine supports all security requited. Even a DESFire card modification, initiated by a remote host, can be securely established as the SAM can act as a “secure proxy” by establishing a secure channel towards the host and another one towards the card, providing a “re-encryption proxy” in the middle. Of course SAM is standard card being “client” and any command exchange, so the reader has to support those protocols by sending, receiving, forwarding APDUs between participating parties.
The SAM also supports direct connections to the reader's chip, acting as a transparent proxy.

It supports 2DES, 3DES, AES, CRYPTO1, RSA, and some proprietary variants of standard algorithms.

SAM has even cleverer concept of “operation counters”, which helps to address the security threat of being stolen and used frequently: each operation decreases a counter. The counters must be periodical increased by a host initiated action, online or offline. Encrypted and signed “scripts” must be brought to the SAM in a way (e.g. USB stick). The keys can be also versioned to support secure roll over of keys during the system lifetime.

The SAM itself has access control logic, based on strong cryptography, to enforce the designed security model. A carefully planned and designed Key Management scheme, supports secure key distribution among the system's many players. Usually, the initial SAM content is distributed by a secure SAM personalisation and controlled delivery to appointed participant (like vending machine vendor), who already has some authentication keys to get initial access to allowed SAM/DESFire card operations. One of typical operation can be authentication keys exchange IF those keys are assigned only to particularly player.

Another comment to UID, its cloning and so on: modern MIFARE products support separate commands to access a RandomUID, to be used in anti-collision protocols, and a static UID to identify the card (optionally also protected by authentication and encryption protocols providing a “secure channel”). This gives to system designers the proper tools to enhance protection against UID cloning or emulation. But many “security designers” are quite lazy anyway and don't use those possibilities even if they exist…


How to capture a TLS resumption traffic using Wireshark?

...normal resumption handshake as described in some document...

It is unclear what some document you are referring to is and what you consider normal. Session resumption can be done with either session id or session ticket. While your capture shows that no session id was used there is nothing known or shown about the use of session tickets. Therefore my guess is that you did not know about session ticket and thus did not look for it.

Also, given that the ClientHello you show in the screenshots have the same random bytes it is likely that both screenshots actually show the same ClientHello (i.e. either from first or from second, don't know) which makes analysis based on your screenshots hard.


Because QuickHash hashes "the file", whereas FTK Imager hashes the internal content of an E01 set.

e.g. if you have 10 image segments (E01 - E010), each segment is a file on disk. It contains the acquired data from the original disk and various values pertinent to the E01 image like CRC checks and metadata. When Quickhash is passed one image segment, it reads the file and tells you the hash of it. When you open an E01 image in FTKi however, FTKi reads all 10 image segments together, ignores the metadata and CRC stuff and hashes the cummlative acquired data. That resulting hash value will match the original hash of the disk.

The QuickHash user manual also explains this.


How can you change platform / OS that is detected by JavaScript in Firefox?

The navigator object is accessed via window.navigator which is in fact a read-only property.

Therefore navigator = fake_navigator; will not work.

However, it is possible to redefine the getter for platform:

navigator.__defineGetter__('platform', function(){
    return 'foo' // customized user agent
});

Querying the property will then return the value within the function.

window.navigator.platform
"foo"

This will fake your platform as far as the JavaScript property is concerned, but Panopticlick is about fingerprinting your browser as a whole, not just taking one property and identifying you through that. Therefore, if you are doing this for privacy reasons then I would not recommend this as an effective measure.


How could our passwords be cracked so easily?

First of all, what you call PASSWORD_SALT isn't really a salt. A salt is different for every password, and stored in the database. What you have is something that is shared by all passwords, and stored in the source code. That is commonly called a pepper.

So how did the attacker crack your passwords so fast, without knowing the pepper? He probably created a new user for himself, so he has one user for which he knows the password. He can then try to brute force the pepper on that user, since he knows what password he should concatenate it to. The key here is that he does not have to crack the pepper and a password at the same time. He can first crack the pepper, and then crack passwords. This is much, much simpler.

A single iteration of SHA-256 is not a good password hashing algorithm. It is way to fast. According to these benchmarks for a 8x Nvidia GTX 1080  setup, you can try around 2 billion hashes per second. If we give the attacker 12 hours, that's almost 1014 hashes. On average, that's enough to crack a pepper with log2(1014) - 1 = 45 bits of entropy. That corresponds to, for instance, 10 random lower case letters.

Once you have the pepper, you can start cracking passwords. Since they probably have lower entropy than the pepper it should be much quicker.

For how to do password hashing right, see this question.


Cisco ASA SYN flood detection and response not working

I wonder if you could've been experiencing this - https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20180418-asa2 (I realise the difference in timeframe however there have been many of these types of advisories over the years) Hope this helps...


Is HSTS (Strict-Transport-Security header) for HTTP or HTTPS?

The HSTS specification draft contains a chapter on the server processing model. It describes the expected behavior for secure requests:

  When replying to an HTTP request that was conveyed over a secure
     transport, an HSTS Host SHOULD include in its response message an STS
     header field […]

And for non-secure requests:

  If an HSTS Host receives a HTTP request message over a non-secure
     transport, it SHOULD send a HTTP response message containing a status
     code indicating a permanent redirect […]

This is also reflected in the various implementation examples of Wikipedia’s HTTP Strict Transport Security article.


Using SUID program to avoid having entries in sudoers

In summary, you mention two possibilities:

adding sudoers entries for apt-get, dpkg, etc. – yes, this sounds dangerous
making your application setuid root – yes, this is a problem; even more so if there's a code path where it doesn't drop privileges very early during execution

There are at least two other options that I can think of:

Write a small setuid root wrapper around the dangerous commands

You can have a small wrapper application which validates how it is being called, only allows operating on a small number of predefined packages, etc. This doesn't remove the liability of having a setuid root application in the first place, but it does greatly limit the attack surface.

It doesn't even really have to be setuid root; it could also be allowed to be executed via sudo. (Though sudo or setuid root doesn't significantly change the attack surface.)

Use a custom dpkg root

This might be the easiest approach. dpkg accepts --root=<somepath>, which is an alias for specifying --instdir  and --admindir. If those two directories are writable by the user, then they shouldn't need root access to work with packages within those hierarchies.

Since by default the tools will only look in the standard locations, your packages won't show up in a standard package listing, system upgrade, etc.; but your management application could presumably take care of that.

The only real downside of this is that it allows the user to mess with their own installation of the software. However, you could in principle use user account separation to reduce that attack surface.

Of these options, unless there's a good reason not to, myself, I would probably go with the custom dpkg root, especially since you already have an application that's going to handle most of the gory details.


Is it safe to use IP Addresses as an identity?

Is it possible for a user to automatically generate ip addresses and fill my database with a ton of spam?

Usually no. As the ISP DHCP leasing mechanisms nowadays try to pin a specific IP to a specific user as long as possible. They would need a zombie botnet of other people's computer to flood your system this way.

  Is it possible for a user to spoof the ip address of another user, and gain access to their links.

Generally yes. Whilst IP spoofing has been made somewhat harder, depending on the protocol; you should assume the IP is not secure or consistent. Besides, users themselve often do not have static IPs

Overall, don't use an IP as the sole source of identity if you can think of other methods.

To avoid using a login you could simply cache their identity in a long term browser cookie or Flash LSO. Users that purge out LSOs (a minority) could get more links by "resetting" their identity (much like newspaper soft-paywalls) - but this depends on how important limiting users to 10 links is for your website.


[Disclaimer: I work as a software developer on the software that powers one of the trusted public CAs, and many corporate internal PKIs]

tl;dr: to my knowledge, there are no formal guidelines for which revocation reason should be used in which situation, it's up to the discretion of the administrator or operator of each CA.

Typically, cert revocations are done by humans who have to choose one of those revocation reasons from a drop-down menu in the GUI. That means deciding which bucket a certain edge-case falls into may vary from one organization / CA to another, or may be entirely up to the discretion of the IT guy who is revoking the certificate for your ID badge, email access, web server, wtv.

In corporate Windows Active Directory CAs:

I found a really old article by Microsoft giving a bit of a text description of each reason -- search for "Revocation Reasons" on the page. (Microsoft built CA software as part of the Active Directory suite, so I assume this is accompanying documentation intended for Windows Domain Admins). See Appendix A at the bottom for the full list.

In the public internet TLS PKI

The CA/Browser Forum (CAB Forum) dictates policy for how publicly-trusted CAs and browsers need to behave with respect to certificates. Here is the CA/Browser Forum Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates, v.1.2.5, April 2015. If you go to section 13.1.5 Reasons for Revoking a Subscriber Certificate (see Appendix B below), there is a list of situations in which the CA is required to revoke a certificate, but no mention of which reason code they're supposed to use.

tl;dr again: to my knowledge, there are no formal guidelines for which revocation reason should be used in which situation, it's up to the discretion of the administrator or operator of each CA.

Appendix A: some guidance from Microsoft on when to use each revocation reason:

  KeyCompromise. The token or disk location where the private key associated with the certificate has been compromised and is in the possession of an unauthorized individual. This can include the case where a laptop is stolen, or a smart card is lost.
  CACompromise. The token or disk location where the CA's private key is stored has been compromised and is in the possession of an unauthorized individual. When a CA's private key is revoked, this results in all certificates issued by the CA that are signed using the private key associated with the revoked certificate being considered revoked.
  AffiliationChanged. The user has terminated his or her relationship with the organization indicated in the Distinguished Name attribute of the certificate. This revocation code is typically used when an individual is terminated or has resigned from an organization. You do not have to revoke a certificate when a user changes departments, unless your security policy requires different certificate be issued by a departmental CA.
  Superseded. A replacement certificate has been issued to a user, and the reason does not fall under the previous reasons. This revocation reason is typically used when a smart card fails, the password for a token is forgotten by a user, or the user has changed their legal name.
  CessationOfOperation. If a CA is decommissioned, no longer to be used, the CA's certificate should be revoked with this reason code. Do not revoke the CA's certificate if the CA no longer issues new certificates, yet still publishes CRLs for the currently issued certificates.
  CertificateHold. A temporary revocation that indicates that a CA will not vouch for a certificate at a specific point in time. Once a certificate is revoked with a CertificateHold reason code, the certificate can then be revoked with another Reason Code, or unrevoked and returned to use.

  Note: While CertificateHold allows a certificate to be "unrevoked", it is not recommended to place a hold on a certificate, as it becomes difficult to determine if a certificate was valid for a specific time.
  RemoveFromCRL. If a certificate is revoked with the CertificateHold reason code, it is possible to "unrevoke" a certificate. The unrevoking process still lists the certificate in the CRL, but with the reason code set to RemoveFromCRL.

  Note: This is specific to the CertificateHold reason and is only used in DeltaCRLs.
  Unspecified. It is possible to revoke a certificate without providing a specific reason code. While it is possible to revoke a certificate with the Unspecified reason code, this is not recommended, as it does not provide an audit trail as to why a certificate is revoked.

Appendix B: 13.1.5 Reasons for Revoking a Subscriber Certificate from CA/Browser Forum Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates, v.1.2.5, April 2015:

  CA/Browser Forum Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates, v.1.2.5, April 2015CA/Browser Forum Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates, v.1.2.5, April 2015:

  The Subscriber requests in writing that the CA revoke the Certificate;
  The  Subscriber  notifies  the  CA  that  the  original  certificate  request  was  not  authorized  and  does  not retroactively grant authorization;
  The  CA  obtains  evidence  that  the  Subscriber’s  Private  Key  corresponding  to  the  Public  Key  in  the Certificate  suffered  a  Key  Compromise  (also  see  Section  10.2.4) or no longer complies with the requirements of Appendix A;
  The CA obtains evidence that the Certificate was misused;
  The CA is made aware that a Subscriber has violated one or more of its material obligations under the Subscriber or Terms of Use Agreement;
  The CA is made aware of any circumstance indicating that use of a Fully-Qualified Domain Name or IP address in the Certificate is no longer legally permitted (e.g. a court or arbitrator has revoked a Domain
  Name Registrant’s right to use the Domain Name, a relevant licensing or services agreement between the Domain Name Registrant and the Applicant has terminated, or the Domain Name Registrant has failed to renew the Domain Name);
  The CA is made aware that a Wildcard Certificate has been used to authenticate a fraudulently misleading subordinate Fully-Qualified Domain Name;
  The CA is made aware of a material change in the information contained in the Certificate;
  The CA is made aware that the Certificate was not issued in accordance with these Requirements or the CA’s Certificate Policy or Certification Practice Statement;
  The CA determines that any of the information appearing in the Certificate is inaccurate or misleading;
  The  CA  ceases  operations  for  any  reason  and  has  not  made  arrangements  for  another  CA  to  provide revocation support for the Certificate;
  The CA’s right to issue Certificates under these Requirements expires or is revoked or terminated, unless the CA has made arrangements to continue maintaining the CRL/OCSP Repository;
  The CA is made aware of a possible compromise of the Private Key of the Subordinate CA used for issuing the Certificate;
  Revocation is required by the CA’s Certificate Policy and/or Certification Practice Statement; or
  The technical content or format of the Certificate presents an unacceptable risk to Application Software Suppliers  or  Relying  Parties  (e.g.  the  CA/Browser  Forum  might  determine  that  a  deprecated cryptographic/signature  algorithm  or  key  size  presents  an  unacceptable  risk  and  that  such  Certificates should be revoked and replaced by CAs within a given period of time).


Would it be more secure to enforce "at least one upper case" or to enforce "at least one letter (any case)"

The effect of a password policy depends on how both users and attackers respond to it. Unfortunately, you can count on your users being lazy and your attackers being creative.

In general, adding more restrictions to passwords has the following effect:

The effective entropy of a good (that is, random) password decreases a little since all forbidden passwords are removed from the attackers search space.
The lazy user might gain a little bit (after all, Password1! is better than password). On the other hand, the burden of complying with all the rules might provoke the user to give up and go with a terrible password that passes the test just to get the god damn form to submit.

In the end, this is an empirical question about user behaviour and not a mathematical about entropy calculations. I'd say that both of your alternatives are about equally bad, but that is just a guess. Fortunately, there are better alternatives:

Drop all conditions (except the lenght one) and instead blacklist leaked passwords.
Consider easing on the other rules and increase the minimum length instead, to 10 or perhaps 12.


If the P2P software isn't explicitly designed for privacy you should assume that it does not provide any privacy.

Some of the data that you are likely to leak when using P2P software might be:

IP address
Any personal files you accidentally share
Any data you provide to the P2P software (e.g. username)
Any data wilfully provided by the P2P software (e.g. version, operating system)
Any data leakage associated with vulnerabilities in the P2P software


Are Ubuntu updates signed by a central authority?

Answering your direct question:
You should read the pages on Secure Apt Ubuntu, and a slightly more thorough page on Secure Apt Debian.
The summary is that packages are signed using gpg (aka "gnupg") which is a distributed web-of-trust style public key infrastructure - this should make you happy. In the PGP / GPG world, people sign each other's keys to form a "web of trust". By default on a new Debian system, there's one trusted key in your apt keyring belonging to
Debian Archive Automatic Signing Key <ftpmaster@debian.org>

so anybody they trust, you automatically trust. If you add a 3rd party repository / PPA to apt, part of that process is adding their signing key to apt's list of trusted keys.
If you want to know more about how packages are vetted, and how signers are added to the trusted list, I'm sure you can find out more by digging into the Ubuntu and Debian communities.
Answering the broader question:
Is it really true that a central authority is less trustworthy than a distributed system? I don't think it is.
Whatever you may think about Apple or Microsoft's requirement to bend to law enforcement, one thing you can be sure of is that they hire good security teams, and that the server holding the signing key is very well secured against hackers - probably with hundreds of thousands of dollars of security equipment and firewalls. Can the same be said of every gpg user who has signing power on the ubuntu repositories? I don't even know how I would go about auditing that ... and that's the point because a web is only as strong is its weakest link.
So yes, Apple or Microsoft may be forced to sign something on behalf of the government (which Apple is spending a lot of money fighting in court, by the way), but distributed systems are WAAYY easier to hack into and steal a key simply because individuals can not spend as much money on security as large companies can. So what's the lesser of two evils: a large security-conscious company under American law, or a collection of individuals who are easily hacked?


Is it safe to browse the web through an SSH SOCKS5 connection to an untrusted proxy?

Accessing an untrusted machine with SSH is a problem in the first place, see What are the risks of SSHing to an untrusted host?, Risks of ssh to an untrusted host?, Is it safe to connect to random SSH servers?.

Additionally SSH only protects the connection between the two SSH peers. That means that the traffic is no longer protected on the untrusted SSH endpoint and that this untrusted system can sniff and manipulate the traffic.


Why does SQL not escape/sanitize by default?

SQL is a programming language. The problem is not a lack of SQL about "sanitizing inputs"; SQL is the input, not something that receives inputs.

The problem is applications that take it upon themselves to automatically generate some SQL based on an haphazard mixing of string elements of dubious origin. An application that suffers from a SQL injection vulnerability, is an application that acts as a code generator. And automatic code generation is extremely hard to do properly when the target syntax was meant for human consumption -- the generator must be aware of all the arcane details of parsing and avoid all the little details and exceptions that are meant to help humans, but make life very hard for machines.

Nevertheless, when there is a need for executing SQL statements with externally provided parameters, a clean solution exists: it is called prepared statements. SQL databases support, and have supported for long, prepared statements. You cannot blame SQL for "not sanitizing inputs" because SQL offers exactly a method for "sanitizing inputs"; you should blame developers for not using it.

(SQL can be blamed for a great number of other things, but not for this one.)


Could you anonymously upload a file on the internet if the threat model was the entire world trying to find your identity after you do so?

Tl;DR

Time is on your side.

Note: leave your own phone at home and preferably own a car without GPS.

Drive 100 miles from home and buy a cheap used laptop/Android device with functioning Wi-Fi in cash from any source with bad/non-existent record-keeping

If laptop then make sure it has the most common OS such as Windows 10
Make sure to park your car about 1-2 miles away from the transaction
If you can grow out your hair and a large beard then do so before this transaction; when the seller gets interrogated then they won't have a clear idea of your facial features. Just try not to make yourself look disheveled or sketchy
Re-format the device to factory settings if possible. Do not install your own copy of the OS
Don't try to install Linux thinking that it's more secure or anonymous because that would narrow down the search criteria to finding people with the knowledge to do such a thing unless of course you are not a person that knows how to do such a thing but were given explicit instruction for achieving such a task. In the latter case you should install Linux to further distance yourself from the main suspect.

Put a piece of tape over the webcam if laptop
Shave your face and cut your hair if applicable
Wait at least one year
Grow out your hair and a large beard again if applicable
Go find some free public Wi-Fi at least 100 miles from both you and the transaction location of the laptop/Android device and connect while outside the actual building; preferably with no surveillance cameras nearby. Park 1-2 miles away.

Alternatively, you could hide in plain sight in a heavily populated mall; in which case an android device would be less conspicuous than a laptop.

Upload the file

You may wish to pass through one or more VPNs

Shut down the laptop/Android device
Get back to your car and drive another 50 miles, remove the hard drive if laptop, and destroy it physically and dispose of it.

Destroy and dispose the laptop/Android device in a different location and drench it in bleach to remove fingerprints

Return home using a different route


Why does Chrome claim that this stylesheet violates the Content Security Policy?

From the documentation of style-src:

  '<hash-algorithm>-<base64-value>' A sha256, sha384 or sha512 hash of
  scripts or styles. ... In CSP 2.0 this
  applied only to inline scripts. CSP 3.0 allows it in the case of
  script-src for external scripts.

So based on this the hashing specification cannot be used for external styles but only for inline styles. The behavior change with CSP 3.0 only allows external scripts this way but not external styles.


I'm looking for an unusual solution that uses SFTP server for data transfer but said SFTP server also should act an encryption proxy i.e. all the data it stores on the server side should be encrypted. Although I could use host (OS-wide) encryption it is not gonna be effective during runtime if the hoster I use decided to peek at it or will be forced by 3rd party or crappy government.

Where do you plan to store the encryption keys? What stops someone with access to the hardware from peeking at the files, using the encryption key?
If it's a virtual server, it's even more trivial for the hoster; they can take a snapshot of memory and the complete state of machine, including key material.
Heck, they could even throw up a proxy in front of your machine, with your ssh keys, and store a copy of the data transmitted, before encryption, without you ever being any wiser.
Refer to the 10 immutable laws of computer security:

Law #3: If a bad guy has unrestricted physical access to your computer, it’s not your computer anymore

What you need in your scenario is client side encryption, where the client handles the key material and encrypts the data before transferring it. This ensures that an attacker on the server side will not be able to decrypt the stored data - as the keys are not present there.


I think that you should use Nmap,or other tool but I use this tool, for this kind of enumeration.

You can use the option -sn to do 80 and 443 ports scan and ping scan, because might be not all of deviced have ping blocked. But if you what to scan other specific ports, you can use -p or --top-ports options.

Then, when you will get the result, you can insert discovered targets on Nessus to do the complet scan.

This is the procedure that I use.


How does automated query compromise other Google users?

You're correct in your assumption that Google blocks this traffic in order to prevent the search service from being slow, but there are indeed other reasons:

Automated searches allow malware to scan for vulnerable web pages, using "Google dorks", i.e. search queries designed to match content on vulnerable sites. This would increase drive-by attacks across the internet, so Google is right to say they are "protecting" users.
Automated queries, if allowed, would probably account for a sizeable chunk of requests. This would cost Google money that they could otherwise spend on making better services for their human users.
You may not realise that your machine is sending automated requests, so the verification page is a good way to alert users, especially since a large chunk of internet users are likely to visit Google at least once in a browsing session. This is a nice way to catch malware.
Tor is a source of a lot of bad traffic, so it's reasonable to expect Google to cut that down to human stuff only. Automated queries via Tor make log analysis and all sorts of other forensic efforts more difficult, so if Google did suffer a breach keeping the automated traffic to a minimum could help.

However, there isn't really a direct effect on a specific user from an automated query. It's not very likely that an automated query would be particularly important from a threat model perspective; if the user is already unknowingly doing automated requests it would imply that they're already infected with malware, at which point their keystrokes and files are compromised already.


How can I find out if a unwanted file I got on my USB Stick in the university lab is harmful? What do do now?

It's a Windows program, it won't magically execute on Ubuntu. And don't bother informing the administrator at the university, most client-facing computers on universities are either locked down hard, or heavily infected.
You don't need to worry about your Ubuntu machine. Unless you have wine installed, and ran that executable by hand, it cannot damage your computer. But you'd better copy your files elsewhere, delete everything from that USB drive, and copying the files back. Not to protect you, but to protect any Windows computer you plug that USB drive later.


Is it safe to reveal information about the OS and the software you use?

Generally speaking, it is not safer to reveal information than to keep it by yourself (but this has exceptions). But "not safer" does not mean "unsafe". If it so happens that revealing information about your OS and software is positively unsafe (i.e. significantly increases risks), then:

You have a problem, because your software has known holes (otherwise it would not be risky).
You have a problem, because your security relies on the attacker not guessing what software you are using, i.e. the attacker not being competent at being an attacker.

If everything is well, then it should not matter whether you reveal information on your OS and software or not. In fact, it has been argued that revealing all the details is better because it allows for more people to contribute to the improvement of the system (that's the open-source mantra, at least). A variant of that theme is that the prospect of the source code being ultimately published and shown to the world at large helps the developer focus on his task. (This last one tends to fail because, as it turns out, many developers lack all sense of dignity and sense of self-worth, and thereby have no compulsion to write better code when external scrutiny is expected.)

In the case of an ATM running XP, the fact that it runs XP matters only for an attacker who can do network connections to that XP machine, and if he can, then he can normally obtain that information himself. Showing the XP login screen still demonstrates a lack of care of the fine details on the part of the system developer, which is worrying (in a general way).


Is there any way to link two different IPs to eachother by identifying the router they came from?

Usually, the assigned IPs are in a small pool.

So you'd get 192.168.0.1, 192.168.0.37, 192.168.0.144.

There are several techniques of browser fingerprinting (you can check the EFF site for that). At the lowest level you check the user-agent. Other methods employ Javascript, Java, and Flash.

You could try to set up your website to distribute cookies and see whether they come back to you. Or you could look into supercookies.

More sneakily, you can supply some link to a site external to yours, for example a CDN link to jQuery. Most CDNs allow relaxed syntax for requesting resources, so you can ask, say,

...library.js?v=17a4&os=win7

and it won't appear suspicious. The library.js file will be downloaded and executed from a site that you do not control. Seems legit.

But what you'll be really doing is set up things so that page processing won't proceed until the library is loaded. And that version number is only sent to guys from that specific network. And in the rest of the page you have another resource that needs loading.

Unless the guy also clears the cache, the next time your page loads it won't even ask for that library, or it will satisfy itself with a 304 Not Modified. So an unknown new guy will take say 400 milliseconds from HTML request to tracking resource. A guy with primed cache, even with different IP, will take 150 milliseconds. And you can set up more than one script with this trick.

You know that the guy is the same as before, because no other guy got that specific fake version number '17a4'.

Similarly, you can have several random thumbnails in one page and see whether the client is requesting them all. If some of them aren't requested (which means the client has them in cache), you can look into a database to whom you served that particular, unique combination of thumbnails (or fake ads, for that matter).

In Javascript you can also access local browser storage; you can use that to store what amounts to a "cookie" that will survive cache clearing (but not local storage clearing).


Probably no.

A phishing attack doesn't rely on using the content of the actual login page, it just relies on the user treating the phishing page as if it were the login page. Even if, as suggested in the comments, you shut your servers down completely, that doesn't mean that your users wouldn't respond to a phishing email pretending to be you.

To elaborate, it doesn't matter how fancy and advanced your underlying security algorithms are. If I can't use your page as it is, I can just (worst case) take a screenshot and drop some forms on it, and this will be good enough for a decent portion of my targets.

If you can't make the page itself phish-proof, you could try to help your users respond better to phishing attempts by training them to recognise your legitimate site and having some part of that site that is unique to them. For example, banks often have a personal image that they show you during the login process. A phishing page is unlikely to be able to accurately reproduce these unique sections, and instead will remove the segment or substitute a generic image. If the user is vigilant, they will notice this and abort before submitting their information.

However, as Adam Shostack comments, there's evidence that training users is unreliable and has a low payoff. Additionally, an advanced phishing page could feed information to the real site and echo back the unique parts as you go along.


Antivirus warns about processes trying to access my webcam

DeviceConsensus.exe is part of a telemetry framework Windows 10 uses to report back on hardware errors. It probably wants to check that everything on your webcam is working right and as for taskhostw Nomad summarize it up very well in the comments.

PS: if you want it to stop asking just go to your privacy settings in Windows 10 then click camera after click Choose which apps can access your camera and uncheck "Feedback hub"


You can and should sign Windows applications : see http://msdn.microsoft.com/en-us/library/ie/ms537361(v=vs.85).aspx


Investigate an unknown device connected to router

There are many free utilities that will do this. On windows I like wireless network watcher from NIRsoft. On mac, try FING
https://www.makeuseof.com/tag/check-wi-fi-network-suspicious-devices/


The certificate used in TLS interception is not a server certificate but a CA certificate. It is not used to authenticate the intercepted server itself. Instead a new certificate will be dynamically created for each visited server and this new server certificate will be signed by the intercepting proxies CA certificate.
In the client the dynamically created server certificate will undergo the usual checks, i.e. matching subject, expiration etc - all fits because it was specifically created as a replacement of the original sites certificate. The trust chain fits too since the proxies CA was explicitly imported as trusted into the client.


You should definitely contact your ISP about this and let them know as this is something they should block.

Some ISP's renew the IP of the subscriber every time the router/modem resets, I recommend you try this too.


Is it possible to have full LAN access through a meterpreter session? e.g. for a MITM attack

Of course.

From a meterpreter session you could run post modules that run on the compromised machine.

You could also use port forwarding in the case you want to connect to Remote Desktop and the port itself isn't accessible from the attacker's machine.

Tools like nighthawk can be used to achieve ARP spoofing (MITM).

It all depends on how stealthy you need to be. Note this is a brief overview and I haven't gone into any depth on these items as your question seems very broad. Feel free to ask a new question covering only a specific item, then link back to this as reference.


Side Channel attacks usually do not leave any traces of intrusion. The attacked program will run without detecting any side effects. With brute force attacks the attacked program is invoked by the attacker many number of times. The attacked program can take counter measures as to check for the frequency of requests.
e.g. brute force would be to try every possible key for decryption of a cipher text.
side channel attack would be to detect/sniff the key by measuring the electric/electromagnetic/cache access characteristics. For RSA encryption if square and multiply method is used it is possible to find out the key by checking the current usage of the device as each step in square and multiply require different power.