Helpdesk role and local admins I need to re-work our current security model for desktop computers, and would like some insight as to what changes can be made as well as best practices.

Currently we have the helpdesk role that is published via GPO to add it to the local admins group on computers. For users that require to be local admins, we deny their computer access to the GPO and add their account to the local admins group. This poses a problem when our helpdesk staff needs to work on the computer when the local admin user is not present. Former admins (that is, no longer working here) placed the users in the helpdesk role that only needed local admin use on their computer.

We now have 30 power users that are now beginning to realize that they can access \computername\c$ shares.

How can I eliminate the helpdesk/local admin conflict without creating GPOs for every computer account?

Can I disable the local admin shares to a specific group and add our power users to that group or is that not a good policy?

This is a perfect example of how Security Groups and the Best Practices concept of Separation of Duties comes into play.

Create security groups for your users, by departmental or functional role - one of those security groups should be something like "Helpdesk-LocalAdmin" (choose something consistent with your own naming convention - if you don't have a standardized naming convention already, it's never too late to establish one).

Create a group policy, call it something like "HelpdeskLocalAdmin", and:

Expand "Computer configuration\Policies\Windows Settings\Security Settings\Restricted Groups"
In the right pane of "Restricted Groups", right click and hit "Add Group..."
Type the name of your Helpdesk Local Admins group, ie: Helpdesk-LocalAdmin and hit 'OK"
Click Add under "This group is a member of:"
Add the "Administrators" Group.
Click OK

Now, for each of your Helpdesk personnel who should be granted Local Administrator account access, add them to the "Helpdesk-LocalAdmin" security group, and the GPO will automatically be applied.

Explanation:
Every "privilege" in a networked / computing environment should be "default deny", meaning that users must be explicitly granted access to network / server / application resources. This allows you to very specifically control who has access to what, instead of attempting to later deny those who shouldn't have access and keep track of them.


Passwords - extended dictionary vs dictionary attacks Taking inspiration from Diceware and the other passphrase generators, I took a dictionary of 20k English words and used a script to generate typos of them, resulting in 7M "words", giving 22.7 bits of entropy per word compared to Diceware's 12.9. 5 of those became part of my new master password (it's easier to remember than 9 words without typos and is only slightly weaker). The setup behind TOR bridges gave me an idea, and I thought of taking this to the extreme and building a passphrase generator with such a large dictionary that it's unbreakable... read on for the fine print.

Just to make the question obvious, I am asking how effective this would be in practice. If it's worth the effort I shall infect my friends and make them replace their correct horse battery staples with this.

The idea is that each user will take a copy of the already large dictionary of common English (or another language) words as their personal dictionary, and then add their own words - uncommon words, typos, names, words in other languages, short phrases, numbers, pseudowords, whatever they can think of (it's their own personal dictonary, if it's not memorable it's their fault). Of course, individual users will have difficulty coming up with enough words to boost the entropy of their personal dictionary by any significant amount, which is why we would go and mix our dictionaries with our friends' to make them larger - they add some of our words to their dictionary and we add some of theirs to ours. There will be a spectrum of word rarity, with a large portion of words being in many users' dictionaries and some few words being unique, at least until you share them with other people.

At the end of the day, with all this mixing, we may have succeeded in adding a few bits of entropy to our own personal dictionary. This may have been equivalent to 1 extra Diceware word. But it gets a little better if we look at targeted attacks:

If they do know our personal dictionary, it still contains the standard dictionary, so it's at least as strong as an equivalent number of Diceware words, which is already secure*. Kerckhoff's principle is still obeyed and the setup can only get stronger over time as more words are added.
If they don't know our personal dictionary... If we have even a single rare word in our passphrase and it isn't included in the dictionary used by the attacker, they will never guess our password. To circumvent this, the attacker may snag other people's dictionaries in hopes of finding one that includes our rare words. They don't know which words are the rare words, so they have no way to filter the combined dictionary. This combined dictionary will also contain lots more words that are not in our personal dictionary and will only slow down the dictionary attack. Guessing entropy is based on how hard the passphrase is to guess, and so in this case it is based not on our personal dictionary but by the (estimated) size of the combined dictionary needed to crack it, and this combined dictionary would be much larger than our personal dictionary.

*But if it's already secure, then why add more security? We can get enough entropy to be secure while still using 6, 5, or even 4 (with a huge dictionary) words, which would otherwise be on or below the threshold for what's currently considered secure. It's only equivalent to Diceware if the standard dictionary is the same size and no user words are added.

I reference Diceware since that seems to be the most popular passphrase generator, or at least it's the one I was pointed to.

This approach would add unnecessary complexity. More importantly, it would also defeat a core purpose of Diceware-style passwords: only having to remember individual words, not weird additional stuff about them.

First, to illustrate the complexity, let's do the math. (For any proposed password scheme, if you do the math informed by a model of the risk, you'll get most of the answer automatically.)

Assuming an extreme worst case - starting with your base 20,000 word dictionary, and assuming that your attacker can guess 100 trillion passwords per second (which is almost certainly beyond current nation-state capabilities), and further assuming that you want your password to resist cracking for 100 years - you would only need:

ceil(log base 20000 of (100000000000000 * 100 * 31556926))

... six words anyway. (Thanks to Jeremi Gosney for teaching me how to illustrate the math).

And that's for a hypothetically advanced future nation-state attacker - which is almost certainly not who you should be worried about. Based on our current understanding of math and physics, millions of words in a Diceware dictionary is completely unnecessary for most actual risk models.

Second, the whole point of Diceware is to make passwords that are easy to remember. Introducing millions of typos would make the cognitive burden unmanageable. Trying to remember those typos would be as bad as trying to remember which letter you capitalized, which 'A' you turned into an '@', etc. It's simply not worth the trade-off - and precisely what Diceware inventor Art Reinhold wanted to avoid.

Instead, for your 20,000-word dictionary, you'd be far better off by simply adding a word. Not only is this easier to memorize accurately ... it automatically (and simply!) increases the cost of cracking the passphrase by 20,000 times.

Alternatively, you could use the american-english-large dictionary that's distributed with some Linuxes, which is 163,730 words. That would drop our extreme case down to 5 words. And instead of wasting energy on memorizing typo variations, you can improve your vocabulary! :)


Why would an attacker include a request body with an HTTP GET request? I have a website that does not run PHP (management decision) or has wordpress installed. Intermittently, I receive a few requests for wp_login pages that trip my IDS. The requests are served with a 404 and I am sure they are just a bot looking for WP administrative pages to attack further.
However, in some cases the GET requests are funny because they contain HTML response from some another server as body. E.g

GET /wp-login.php HTTP/1.1
Host: myhost
Keep-Alive: 300
Connection: keep-alive
Cookie: charitable_session=<SESSID>;wordpressuser_<ID>=+; wordpresspass_<ID>=+; _wp_session=<SESSID>%7C%7C1472773689;
User-Agent: Mozilla/5.0 (Linux; U; Android 2.2) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1
Content-Type: text/html; charset=utf-8
Content-Length: 35870
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en,en-us;q=0.7,es;q=0.3
Accept-Charset: utf-8;q=0.7,*;q=0.7

<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml" lang="en">
<head>

<title>Oops! The page you are looking for does not exist.</title>

<meta http-equiv="X-UA-Compatible" content="IE=edge" />
<meta name="generator" content="Flynax Classifieds Software" />
<meta charset="UTF-8" />
<meta name="viewport" content="width=device-width, user-scalable=n

o, initial-scale=1, maximum-scale=1" />

<meta name="description" content="" />
<meta name="Keywords" content="" />

<link rel="stylesheet" href="http://tiruvannamalai.co.in/templates/general_wide/css/style.css" />

This answer of stackoverflow says that webserver SHOULD ignore the request body and I am sure my web-server does so.

My question is what possible benefit can somebody derive from such a scan? Is it just a buggy code that pipes response from one scan into another (Seeing that even headers such as Content-Length are added to request)?

Could be deliberate, though nothing obvious leaps out from that specific body.

There are techniques like request smuggling that involve subtle protocol violations. See for instance:

http://www.cgisecurity.com/lib/HTTP-Request-Smuggling.pdf

Might be interesting to see if the length of the request body is in fact 35870, or if something interesting appears at that place in the request stream.


Which verification method should I choose: SMS or call? I want to enable Two-Factor Authentication for my outlook account, but I'm not sure which method should I choose or in other words which method is more secure?

Like I said there are two options: text and call and I think there are some advantages and disadvantages of both methods.

Call is safer, for reading your sms you only need a simple program whereas for monitoring your calls, you need an actual person, thereby increasing the effort needed by a lot.

Reading sms is something you can do on as many phones as you want whereas listening to that many calls at the same time is impossible (unless you're the NSA I guess). Even if you found a way to just record the call and then send it, the programming effort here is much greater and you also need a lot more processing power and bandwidth, once more lowering the chance that you're gonna be caught by it.

edit: I just want to add, of course the other guys talking about your threat model are right. If you leave your phone lying around and people can just take it and listen to the code, of course sms would be better. But then again, if you don't even have a lock on it, it wouldn't matter.

As you can see, yeah, it depends, but if you do have a passcode and you're not leaving your phone lying around, calls are better.


Do any web browsers create cached copies of local HTML files? Suppose that we create a sensitive file as a HTML document, and then view that file with a web browser such as Firefox, or other.

Is it possible that the file is treated as if it were a document fetched over HTTP or HTTPS, and stored in the browser's cache?

If this is the case, we have to wipe the browser's cache and shred the free disk space in order to be sure that the secure document is gone, making it inconvenient to use that browser as a reader for secure documents.

Are there any browsers, or specific versions of browsers on specific platforms, which have such a dumb behavior (and should not be used, for instance, as tools for viewing temporarily decrypted sensitive documents?)

Local files are not treated any differently from Internet sourced files in terms of caching, temp files, etc.

If you use a system file change tool and open a local *.html file you will see that all sorts of files across the system are modified or at least opened. I tried a test file on a local drive in both IE and FireFox and it looks like a few files were modified. I would recommend you do further testing, but I see not reason why local files wouldn't be cached, etc. Just because they are local does not mean the browser does not need to store data or information from the page temporarily, in history, etc.

You can try a few different file/folder change monitoring tools:

Track Folder Changes

I would generally not think HTML is the best thing to use for secure documents. The documents are not going to be secured at rest and there could be malicious plugins or other software within the browser. I would recommend using PDF with strong encryption/passwords. A lot of virtual printers (e.g. will print to PDF) include the ability to add AES level security, one such program is PDFCreator. In that way the file is secure at rest as well. I do not believe there is any caching in Adobe Acrobat or Adobe Reader, but I will have to double check on that, and could not comment on other PDF readers.


openssl blowfish key limited to 256 bits? I get the following error if I give a key that is greater than 64 hex caracters (64*4=256 bits).

According to this official document, blowfish is able to support key from 32 to 448 bits.

  Variable key length: 32 bits to 448 bits

Is it possible to bypass this limitation? What's wrong?

The actual key size is big enough, but I would like to have the most security as possible.

Thanks,

For OpenSSL's command-line program (openssl enc), the algorithm chosen also picks the key size (which is why they have separate options for aes-128, aes-192 and aes-256). They just don't have this option for Blowfish.

  The enc program only supports a fixed number of algorithms with certain parameters. So if, for example, you want to use RC2 with a 76 bit key or RC4 with an 84 bit key you can't use this program.

openssl enc -bf always uses a 128 bit key:

  Blowfish and RC5 algorithms use a 128 bit key.

The documentation for the Blowfish functions says you can use a variable-length key, so presumably if you wrote your own program compiled against OpenSSL, you could use whatever key size you want:

  BF_set_key() sets up the BF_KEY key using the len bytes long key at data.

If you can choose your algorithm, and you want a longer key for whatever reason, OpenSSL will do AES with up to 256-bit keys: (openssl enc -aes-256).

Given the above, you'd expect OpenSSL to complain when you go over 32 character (32 * 4 = 128), but it seems to silently ignore any data after the first 32 characters:

  blong@ubuntu:~$ openssl enc -bf -iv 0 -P -K 000000000000000000000000000000012345
  salt=0700000000000000
  key=00000000000000000000000000000001
  iv =0000000000000000

I submitted a bug report, because it looks like they're trying to catch this case, but the error is for > 128 characters instead of > 128 bits.


Is there any way to protect a client-side game from a hacked client? Here's a toy example of a game: the player is presented with N slot machines. They can click on each slot machine once, and when they do so, the slot machine rolls a random outcome (based on a predetermined set of outcomes and probabilities).

If the slot machine outcomes are rolled on the server, there is obviously no opportunity for the client to cheat: the server has full information to arbitrate which slot machines have already been rolled and what their outcomes were.

Suppose the client and server communicate only twice: once before the game starts, and once after the game ends. Is there any kind of protocol that can guarantee that the client cannot cheat?

Obviously, the client cannot simply report to the server what rolls the player achieved on all the machines; the client simply reports N jackpots.

Better would be for the client and server to agree on a method of determining the slot machine outcome, based on the image of a one-way function of the time stamp when the client clicks the slot machine. The client reports to the server the (time stamp, outcome) pairs for each slot machine, and the server can verify that the outcomes are correct given the time stamp.

But this protocol is still not secure; it may not be tractable for the client to invert the mapping from time stamp to jackpot, but it can try many possible time stamps and report to the server the N most favorable outcomes.

Is there any protocol that can guarantee (perhaps given additional assumptions about the computational power available to the client) that an untrusted client cannot cheat at this game? If not, is there an argument proving impossibility?

No, you can't protect your game from cheats if rolls are made from the client.

The main point of failure of your protocols is here

  The client reports to the server the (time stamp, outcome) pairs for
  each slot machine, and the server can verify that the outcomes are
  correct given the time stamp.

And you demonstrate its vulnerability below

  But this protocol is still not secure; it may not be tractable for the
  client to invert the mapping from time stamp to jackpot, but it can
  try many possible time stamps and report to the server the N most
  favorable outcomes.

Nothing prevent the client from reporting a false timestamp.
Moreover, even if there were a way to force the client to report every rolls correctly, in your particular case of a slot machine, the fact that the client might be able to guess its next rolls would be a critical vulnerability.


Any comprehensive solutions for binary code protection and anti-reverse-engineering? Does anyone know of good products with comprehensive binary hardening and anti-reverse-engineering features?  Or better, has anyone seen an independent review comparing products that perform these types of binary code protections? I've only found one or two that offer comprehensive solutions:

Arxan GuardIt http://www.arxan.com/software-protection-products/index.php
PikeWerks http://pikewerks.com

Of these even Arxan seems the most comprehensive in terms of its protection mechanisms.  The types of features I'm looking for include:

protection against reverse engineering
protection against BORE attacks (break once run everywhere)
protection against tampering
protection against binary modification

To provide these features the products would implement many different techniques in the larger categories of:

static and dynamic binary obfuscation
virtual machines
static and runtime encryption
checksums and timing
anti-debugging
authentication

For example, to implement static binary obfuscation the product should offer many different techniques from basic constant and export renaming to path chaffing, fake code insertion, and others.  For a good reference see Andrew Griffith's paper on Binary Protection Schemes at  felinemenace.org.

I don't know much about PikeWerks but I like how Arxan's product sounds like it conveniently integrates into a build environment so no custom code is required.  Furthermore it seems to have capabilities not only to defend but to detect and react to attacks.

* Update *
I should have listed the platform requirements:  Linux, x86, x64, Java, C, and C++.

The more you invest in protecting your binary from crackers:

the less of your project cost is being invested in adding value for the customer
the more expensive your product becomes, driving away legitimate customers
the longer your time to market, allowing a less conservative competitor to execute faster

Virtual machines are part and parcel of the way IT departments are run now. Avoid running in a VM and you avoid selling your product to part of the market.

Tamper-proofing/Authentication should probably be handled by an OS feature: I know that Windows, Mac OS and many smartphone platforms already support that. My main area of expertise is OS X, which has a "kill" flag such that a process that becomes unsigned can voluntarily suicide. An application can test its own signature, which comes with the proviso that if your app's been cracked you can assume that the test has been changed or removed too.

Obfuscation/encryption techniques are worthless: at some point the CPU has to see the instructions that it actually needs to run, and at this time those instructions can be dumped out to result in the "clean" binary.


Is my server safe from remote hackers if I only allow 1 port and 1 service behind it which only hashs incoming bytes stream & send the hash key back? I have a python script ,which accepts an incoming connection, reads from the byte stream ,hash it (I'm pretty sure the hash function itself can't be exploited) ,sends the hash key back ,then closes the connection .

Is my server secure (by secure I mean the data on my server is not leaked ,doesn't have to be serving 7x24 under attacks ),if I only allow the port my script is listening to (say 30000) and ban all other ports ?

Nothing except the operating system (in this case ,ubuntu )and the python script mentioned above is running on this machine .I don't use this machine to do anything other than this (like browsing web pages etc ,I don't do it on this machine ).

No. The question is not the number of open ports but which services are behind these ports and the security of these services. Thus, it is sufficient for an attacker if there is only one open port which one service but this service is exploitable.


How can I double check security against a TLS on a public IP? Dilemma

We are setting up a docker registry server for our company as per these official indications: https://docs.docker.com/registry/deploying/#run-an-externally-accessible-registry.

We are evaluation what option to implement:

More secure, less practical: Put the server in a private net behind a firewall, accessible via ssh, and then have developers to manually open a tunnel (for example a SSH tunnel) from their homes over the world everytime they want to use it.
More practical. Question is: More insecure?  Placing the docker registry server in a public IP and protected with TLS. Developers just "push" there over a TLS channel. TLS will be build on top of keys/certificates CA'd by Let's Encrypt with a domain-verification.

For this question let's assume there are no home-residential-IP ranges allowed from the home of the developers and let's assume the server being reachable from 0.0.0.0/0

On-topic, Off topic

I already know I can improve the security by firewalling residential-home CIDRs assigned by the ISPs to the remote developers and so. That's not the topic of this question.

I want to focus the question on having a server with private data running in a public IP on a public port, and using TLS over it.

Affraid

I'm a bit affraid of that. I usually had always all my ports closed to the public except for 80, 443 and 22. To administer we usually allowed SSH from anywhere without problems.

For example if I had a MySQL I had 3306 only "from the inside" and we had to connect first via SSH and then use the SSH tunelling to connect to it.

Putting a MySQL against a public IP and protected "only" with TLS goes against my inctuition. But maybe it's as secure as having the SSH and I didn't know.

Previous investigation

I see that properly configured TLS is as secure as SSH (see similar questions here: Is connection established with two way SSL as secure as SSH?).

There is also extensive documentation on the version of TLS and so: https://en.wikipedia.org/wiki/Transport_Layer_Security

The new v1.3 finished on 2018 seems to be "ultra secure": https://www.ietf.org/blog/tls13/ can I blindly rely on it?

Questions

The word that scares most me is "properly" configured.

1) How can I know if this combination:

The latest registry image https://hub.docker.com/_/registry (currently at the time of writing 2.7.1)
A certificate obtained from let's encrypt with the latest available certbot in "manual mode" running the latest docker image https://hub.docker.com/r/certbot/certbot (currently at the time of writing 1.3.0)
The instructions of merely adding the TLS certificate in the registry https://docs.docker.com/registry/deploying/#run-an-externally-accessible-registry

...how can I know if this combination protects me as much as an SSH connection does?

2) Is TLS 1.3 "Much" better than 1.2?

3) How can I know if my setup is using TLS 1.3?

4) Provided the registry will have users/passwords, setting TLS is "secure enough"?

5) Does this mean that on a hurry, if I had a DB exposed to the public but running on a TLS would it also be as secure as having an SSH there?

TLS only protects the communication between client and server against sniffing and modification. This means that it does not make an server side application magically secure against attacks from a malicious clients. It also does not make any existing authentication methods stronger, i.e. weak password will still be weak passwords and they are as easy to crack as without TLS. TLS can add a way more secure authentication method though in the form of client certificates.

Based on this the more secure approach is your first proposal, where the user first needs to authenticate against the SSH server (hopefully key based authentication and not passwords) and then can access the docker registry server. This is more secure since it hides everything behind an additional and strong (if key based) layer of authentication.

With proper authentication like client certificates the web interface of the docker registry could also be made public, but then you loose the protection of the additional SSH based authentication layer. Anything except the web interface should not be made accessible from outside, i.e. no database etc. But as far as I know this is also not needed for a docker registry.


Server secured with a Certificate from a Custom CA Root: OK on Firefox but KO on Chrome? The Setup

In order to protect the very small intranet of the ACME company, which contains two private servers, foo-server and bar-server, I've created with OpenSSL:

The Root CA Certificate
The Intermediate CA Certificate
The ca-chain file, containing the Intermediate CA but not the Root CA
The foo-server certificate
The bar-server certificate

I've bundled the chain and the certificates and configured one NGINX on foo-server and one APACHE on bar-server.

I've then installed the Root CA on my local Firefox and on my local Chrome.

Note that I've not used any SAN: for now, the certificates are issued for server names only (eg foo-server), NOT for their full names (eg. foo-server.ACME.local).

The Result

When I open https://foo-server/ and https://bar-server/,

On FIREFOX

Everything is OK. I see both of them secured (as it should be) because the server sends the chain properly, and I have the CA Root Certificate installed.

On CHROME

I get the following error on both of them, but the Common Names are perfectly fine:

  NET::ERR_CERT_COMMON_NAME_INVALID

The Question

Since I'm really noob at this (I'm a Developer playing with SysAdmin toys), I would not be surprised to discover that the problem is something naive for you, but unknown to me.

What could be the culprit? What could I check? Maybe Chrome doesn't recognize a server name with no domain?

Chrome requires SAN present in the certificate.


What information is being transmitted to the carrier when making a call on a GSM network? I was wondering how carriers could track your calls and phone. I know that that there are a few things that are sent to the cell towers (and then to the carrier if it is logging the information) when making a call.

Correct me if I am wrong.

I think that it must must be the number, IMEI (to identify the phone) and location of the cell tower which handles the connection to the phone (other possible data is also the number to which the phone is calling and the date and time of the call).

Are there any more things that are being sent like for instance, phone model SIM card information or something that I am not aware of?

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

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

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


Random string vs hash(random string)? I'm implementing a one-time token service. Each of these one-time token represents some server side data/action associated with it (a 'email confirm' action for example), so that my web service can verify and take action when receiving them without session. (from inside a email's confirm link; from a qr code scan; ...)

These token should be very hard to guess or forge. So i think a long random string (from /dev/urandom) should be well enough. But from https://en.wikipedia.org/wiki//dev/random:

  A counterpart to /dev/random is /dev/urandom
  ("unlimited"[5]/non-blocking random source[4]) which reuses the
  internal pool to produce more pseudo-random bits. This means that the
  call will not block, but the output may contain less entropy than the
  corresponding read from /dev/random. While /dev/urandom is still
  intended as a pseudorandom number generator suitable for most
  cryptographic purposes, some people claim /dev/urandom as not
  recommended[who?] for the generation of long-term cryptographic keys.
  However this is in general not the case because once the entropy pool
  is unpredictable it doesn't leak security by a reduced number of bits.

And also i have read some code in werkzeug's session https://github.com/mitsuhiko/werkzeug/blob/master/werkzeug/contrib/sessions.py

def _urandom():
    if hasattr(os, 'urandom'):
        return os.urandom(30)
    return text_type(random()).encode('ascii')

def generate_key(salt=None):
    if salt is None:
        salt = repr(salt).encode('ascii')
    return sha1(b''.join([
        salt,
        str(time()).encode('ascii'),
        _urandom()
    ])).hexdigest()

So my question is: Is such hash(time()+urandom()) generate more 'random' string than pure urandom()? What is the purpose to use a hash function here?

Real random data are 100% unpredictable. Interfaces like urandom additionally provide uniform distribution on top of this, i.e. you get not only unpredictable random values but all values have the same probability. If you already have such a high quality source of randomness then hashing will not improve it any more, i.e. hash(time()+urandom()) will not be better than urandom() alone.

But the code example you have falls back to the simple random() function if urandom() is not available. This is usually only a fast pseudo random number generator where the values are somehow predictable if you know enough of the previous values. Thus hashing the output together with a salt and the time might be an attempt to make the output less predictable when faced with a pseudo random number generator only. And while it does not really add more randomness to the output, it makes it harder to get back to the original pseudo random value and thus makes it harder to use attacks against the underlying pseudo random number generator. For real random data you don't need such kind of protection because the input data are fully unpredictable already and there is no way to compute the next random value if the previous ones are known.


Difference between Privilege and Permission I am a little confused on the contextual differences between permission and privilege from computer security perspective.Though I have read the definition of both the terms but it will be nice if someone can give me some practical example e.g.

User A can read write file X

What is privilege and permission in this case ?

In computer security, they are used interchangeably.

  In the context of rights, permission implies consent given to any
  individual or group to perform an action. Privilege is a permission
  given to an individual or group. Privileges are used to distinguish
  between different granted permissions (including no permission.)

A privilege is a permission to perform an action.

Also from the above english.se link

  A permission is a property of an object, such as a file. It says which
  agents are permitted to use the object, and what they are permitted to
  do (read it, modify it, etc.).

  A privilege is a property of an agent, such as a user. It lets the
  agent do things that are not ordinarily allowed. For example, there
  are privileges which allow an agent to access an object that it does
  not have permission to access, and privileges which allow an agent to
  perform maintenance functions such as restart the computer.

So in your example the privilege is having the permission to write the file 'x'


How can I explain our system admins that AV can't protect our enterprise machines from attacks leverage on USBninja? Was hoping to get your support to help to explain to our system admins how come the AV can't protect our enterprise from attacks that can be generated from USBninja. How can I explain our system admins that AV can't protect our enterprise machines from malware that come from USBninja?

It surprises me that you have to. But then, they might be unfamiliar with the USBninja. Explaining what the USBninja does should be sufficient for sysadmins. But the best way is to show them. Buy one. Set-up a HID-script that copies some data from the system to your USBninja. And have them run their anti-virusses at their leisure.

In mass storage mode, the USBninja is detectable by anti-virus. It will behave as a storage device, which might be useful if you want to extract larger chunks of data. However, you will probably not put a virus on it.

Experiment a bit with HID scripts. Get a few from the Internet like:

DELAY 5000
GUI r
DELAY 1000
PRINT notepad
ENTER
DELAY 1000
PRINT Hello, World!

In general, a short presentation, followed by a demo should be sufficient.

First explain what anti-virus does (signature detection, sometimes program behaviour)
Explain what a USBninja does. Especially, explain the HID-mode. Make them understand that anti-virusses do not protect from keyboards.
Demo-time!
For fun, buy some cheap USB-cables that you leave scattered around the room. If they understood the message, no-one will dare to use those cables.


Bypass bcrypt max input I was reading this question regarding bcrypt max password length.

Is there a preferred method or way to allow user passwords to be unlimited length? Or at least much higher?

Is there an alternative library? Or a full alternative method? Currently I'm using Node with this npm package.

The 72-character limit is caused by Blowfish cipher, which is used internally for Bcrypt. You can limit the length of the password in your application, truncate it, or (may not be the brightest idea) hash it and pass the output of the hash function to Bcrypt. Either way, it is not possible to beat the Bcrypt cipher's internal limit.


How to check which certificate is being checked for revocation? I have a .net desktop application without a certificate on a network not connected to the Internet

When I start it, there is a call to crl.microsoft.com that times out and slows down the application.

I know I can put

<runtime>
    <generatePublisherEvidence enabled="false" />
</runtime>

to skip the check, but I'm curious to know what triggers this check and which certificate does it want to check? Is there a way to "sniff" that information?

This MSDN blog may help you

One way of doing this is listed below, but others are on the blog

REGISTRY  : HKLM\SYSTEM\CurrentControlSet\Services\HTTP\Parameters\SslBindingInfo
DWORD    : DefaultSslCertCheckMode
Value         : 1


What are the cons of stateless password generators? Does anybody have hands-on experience with stateless password generators (managers) like Getpass?

It seems like it does most of the work of cloud password managers, but leans more to the security side as there is no servers with passwords to penetrate.

I have used a stateless password generator for years, and I think there are a lot of drawbacks:

If your master password is compromised, all of your passwords are. In comparison, standard password managers requires that the attacker both compromise the master key and gain access to the password store.
If a website has a password policy, you might not be able to generate a password that respects it.
If one of the password needs to be updated for some reason, you need to keep that state somewhere. For example, you need to remember to generate a password for "StackExchange2" instead of "StackExchange".
If you already have some passwords that you can't change (for various reasons), a static password generator won't help you.

For all those reasons, I think you should definitively use standard password managers.


How to protect printers from being hacked Recently it got to my attention that someone has hacked around 50,000 printers and used them to print the message they wanted to. (link)

As someone who doesn't have a lot of knowledge about networks or hacking, what would be the steps to take to protect my printer or similar accessories from such attacks in the future?

Don't leave your printer exposing port 9100 to the internet.

This large-scale printer attack is nothing new. It's happened previously and is very simple to execute.

The attacker likely used Shodan to scan the entire internet for printers with port 9100 open to the internet. Due to way RAW printing over port 9100 works, all is required after this is to connect to the printer on port 9100 TCP and send the text you want to send to the printer.

Preventing this attack

All you need to do is close port 9100 externally. If there is a requirement to print remotely, this is possible in a number of ways:

Use a VPN to connect to the network, making the printer accessible as if it's in your local network
Use a different printing protocol

IPP. This is designed to be used over the internet and has built in support for authentication.
Google Cloud Print


Is running software in Docker an allowable way to bypass FIPS 140-2 issues? Someone has a service that uses a FIPS non-compatible hash in a protocol signature.  When FIPS 140-2 compatibility is enabled on the hosts the service crashes (due to the hash signature being not allowed by the security configuration of the host).  A way to get around this is to put the service in a Docker container on the FIPS compatible host.  It works, but is it ok from a FIPS compatibility point of view?  If not, why?

You are basically asking if it is ok to ignore FIPS 140-2 requirements for a specific task, the actual way you do this does really not matter. It is unknown if this is acceptable or not in your specific use case. But at least you can no longer claim that all the cryptographic operations you do on the machine conform to FIPS 140-2 requirements.


Reason for using Asymmetric encryption along with SHA256 I got a document with integration with another application. They mentioned I need to hash and then encrypt data with my private key before sending it over HTTPS. By doing this, they are making sure that data was not altered in the middle of transit.

I wanted to know what is the reason for three layer security(SSL+SHA256+RSA). is SHA256 weak by itself or are there other concerns which I am not aware of?

The document your are reading uses the flawed analogy "encrypt with the private key". In asymmetric encryption, you encrypt with the public key, and you decrypt with the private key. "Encryption with the private key" is the way digital signatures were first described, because that kind of works like that in RSA. But the analogy does not work with other signature algorithms like DSA, and, when you look at the details, you see that it does not work with RSA either.

So just forget the word "encryption" here. They ask for a signature. A signature begins by hashing the data which is to be signed (with a hash function like SHA-256), and the rest of the computation involves only the hash output and the private key. The signature is not used in addition to SHA-256; SHA-256 is an element of the RSA signature process.

Why would they ask for a signature ? SSL already ensures data integrity. But they may want non-repudiation. When using SSL, client and server establish a tunnel for data; the client has some guarantee that it talks to the right server; if some authentication occurred (e.g. with a user name & password sent through the SSL tunnel), then the server also has some guarantee that it talks to the right client. The SSL mechanics also guarantee that the data is not eavesdropped on or altered while in transit.

What SSL does not do, however, is to produce proofs which could be shown to a third party (e.g. a judge). If there is some ulterior legal trouble between the client and the server, the server has nothing to show to a judge to demonstrate that the client sent a specific request. When the server receives the request, it is well convinced that it comes from the client, but the server cannot prove that it did not make a fake request to incriminate the client. To have such proofs, you need something else. That something else is partly technical, partly legal; the technical part is digital signatures (the legal half depends a lot on the jurisdiction, so there is no absolute answer here).

Summary: the other application wants a signature. SHA-256 is part of the signature process, not a redundant step. A signature is requested probably in order to achieve some sort of non-repudiation, which raw HTTPS does not provide (it might also be an overkill of an authentication system, though).


How can you reset a UEFI completely in case of a firmware infection? I haven't really understood whether firmware level infection (on either motherboard or drives) can actually be a thing without physical access, however how can one factory reset the firmware in that case?

Is there, in particular, a way to be sure it was reset to a clean version, without interference from a malicious edited firmware? Do motherboards have some sort of uneditable, ROM-stored version you can fall back to? It seems so lame if editable firmwares in motherboard simply created new security risks...

I haven't really understood whether firmware level infection (on either motherboard or drives) can actually be a thing without physical access

It's possible because you can update the firmware on many boards without actually needing physical access.  The common case is to use the EFI Capsule Loader interface, but there are other methods out there too, one of the scariest being the use of Intel AMT to reflash firmware remotely with zero interaction from the user (there are actually systems that can do this).

  however how can one factory reset the firmware in that case?

Any method of doing it with the system powered up requires cooperation from the firmware itself, and it's pretty trivial for the malware to just not cooperate (in fact, it's actually easier for them to not cooperate than it would be for them to cooperate).  As a result, you need to physically remove the flash memory chip that contains the firmware, and then manually reprogram it using specialized hardware (well, specialized from a typical end-user perspective, you can use pretty much any SPI flash programer you want as long as it has the right interface).  DOing that is going to be functionally impossible for most people, mostly because it's nearly impossible to get the raw firmware image out of the update packages from the vendor (the hardware to actually program it is cheap, and it's not something that takes more than some really basic skills to use).

  Is there, in particular, a way to be sure it was reset to a clean version, without interference from a malicious edited firmware?

Verifying the firmware image you're going to use is sufficient, provided you actually reprogram it correctly.

  Do motherboards have some sort of uneditable, ROM-stored version you can fall back to?

As a general rule, no, it would be wasted space and power for 99.9% of end users, and would also be a logistical nightmare for the support staff.

Many good motherboards do, however, use transactional updates and have a backup copy of the firmware (it starts as the same version, and then after the first firmware update it tracks the last used version.  This doesn't really help though because anything that can rewrite one can just rewrite both.

  It seems so lame if editable firmwares in motherboard simply created new security risks...

Updatable firmware is not something new.  The concept has been around for far longer than most people realized (the oldest PC's I've seen that could do it without needing programming hardware or a manual chip swap are from over a decade ago).  It's only recently that it's become really widespread though because UEFI makes it much easier for the OEM to provide support for it.


What is the security purpose behind the "enable editing" of MS Word? Whenever I open MS Word documents from my email, they open in "Protected View" with edit options disabled by default.

As per my understanding, the hyperlinks used in the main document would be linked with spyware.malware so enabling the edit option will lead to spread of malware. I have also heard about Macro virus which are capable of spreading while the file is opened

Are there any other reasons behind the protected view of Word files?

Thanks in advance

Well macro's would allow you to automatically start running scripts on the machine once the document was opened. Hence they get opened in a protected mode to prevent code execution from happening automatically (the user needs to aprove it explicitly).

Also from the MS website:

  Files from the Internet and from other potentially unsafe locations
  can contain viruses, worms, or other kinds of malware that can harm
  your computer. To help protect your computer, files from these
  potentially unsafe locations are opened in Protected View. By using
  Protected View, you can read a file and see its contents while
  reducing the risks.


Meltdown and Spectre regarding Firewalls and Sandboxing I don't deeply understand Meltdown and Spectre -- all I know is that they are basically keylogging-like vulnerabilities within the CPU, which bypass any application layer stuff; correct me if I'm wrong.
I want to know the following:

Why is application sandboxing ineffective against Meltdown and Spectre? In other words, (based on my understanding above) why is the application layer bypassed?

Let's say the Meltdown and Spectre vulnerabilities are used by some malware and the malware sends keylogged information to a remote host. If I have a firewall, such as Iptables, and I restrict outgoing traffic, will that be enough to prevent the malware author from stealing information?
In other words, will a firewall be able to prevent the 2 vulnerabilities from passing information to a remote destination?

Meltdown and Spectre are hardware vulnerabilities. They actually reside in your processor and are interested in sensitive information.

Meltdown is specific for Intel Processors.

Spectre is for processors other than Intel (not Intel).

Meltdown bypasses the 'protection mode' that is present when you want to access sensitive data that is stored in your processor.
The attack imitates the role of a normal user that is accessing the
data. The reason sandbox is useless is because the operating system
thinks it is a normal user not an attacker.
It could be possible that firewall will detect the malware. This will require software patches (updating your Operating System version).

In conclusion

Most computer providers have released software patches to overcome these issues. Since these are hardware related, it means that the hardware is what needs to be improved. Software can help, but not fully.

UPDATE

Built-in Firewalls are updated along with the Operating System (OS), since Firewalls are human programmed, they need to know how malware activity behaves. So, if the most recent version of OS is running on you device, the likely hood that your Firewall will know that this malware is carrying out Meltdown or Spectre 'activity' is high. This is because they are now aware of how these vulnerabilities will act.

As for outgoing traffic, and in terms of Iptables, it is unlikely that you know which IP address is trying to access your data.

I would also like to emphasise, again: Software can help, but not fully.

Hope it is clear now.

End of UPDATE

References:

Kocher, Paul, et al. "Spectre Attacks: Exploiting Speculative Execution." arXiv preprint arXiv:1801.01203 (2018).

Meltdown and Spectre. (2018). Meltdownattack.com. Retrieved 1 April 2018, from https://meltdownattack.com/#faq-fix


Can global adversaries 'de-anonymize' any Tor user in a day? Tor traffic correlation attacks by global adversaries
I know what traffic correlation attack is but I find it hard to understand this article or how it got to its conclusions about 'de-anonymize' 'typical web user' who use Tor within a day just with the ability to monitor enough web traffic. I also don't get how dark markets and child porn still exists on onion sites if all it takes is a little bit of cooperation to de-anonymize everyone?, The article is from 2013 so the governments had a long time to do it.
At the end all what the 'global adversaries' can see is traffic volume and timing(that is affected by some timing noise) right? so if you are just a typical web user who just connected few times(lets say 5 times) to an average website/webpage with an average size of 700kb who said that you are one of the few Tor users who visited a website/webpage in this size 5 times around the time you did it?. I am missing something here?.

TL;DR: correlation attacks are a possibility but there is always a gap between theory and practice. The other limitation is scalability.

An excerpt from that 2013 study shows that the technique is not that trivial:

  Our analysis shows that 80% of all types of users may be de-anonymized
  by a relatively moderate Tor-relay adversary within six months.  Our
  results also show that against a single AS adversary roughly 100% of
  users in some common locations are deanonymized within three months
  (95% in three months for a single IXP). Further, we find that an
  adversary controlling two ASes instead of one reduces the median time
  to the first client de-anonymization by an order of magnitude: from
  over three months to only 1 day for a typical web user; and from over
  three months to roughly one month for a BitTorrent user. This clearly
  shows the dramatic effect an adversary that controls multiple ASes can
  have on security

The other takeaway from the study is that you still need time, even a lot of time for uncertain results. The study does not suggest the ability of real-time deanonymization.

One thing we have learned in IT circles is that encryption in general is seldom defeated, but circumvented. People get caught because of opsec failures and lack of understanding of the tools they use.

Let's put the Tor network aside for a minute.

A browser has a huge attack surface. Even the Tor browser, which is configured with hardened settings is not immune to bugs or 0days. Javascript (which I understand is enabled by default in the Tor browser) gives away many small bits like the local time (which can be used to infer the timezone) and other bits of information that can be used for fingerprinting the browser or the user. The small bits add up and it is a start.

Now imagine an alphabet soup agency is after you, and they have some 0days in store, and they can weaponize a flaw in the Tor browser you are using. If they manage they take control of your computer, execute malicious code in the context of your user, or manage to leak your IP address you are done.

In this scenario Tor was not directly compromised. Sounds like something they could do or have done ? Probably.
There is an obvious limitation to this approach: a good 0day is expensive, therefore you cannot waste it against a low-value target because it is going to be noticed in the wild and ultimately fixed.

Bottom line: if you do something illegal or objectionable on Tor, you should be not using it from your home connection. Instead, you should borrow some public/restaurant/library connection and move from place to place. Preferably where cameras are rare. Most likely, this is the most effective defense against deanonymization attacks.

How do criminals using Tor get caught ?

From what we know it's not because of a weakness in Tor but because they did stupid things, like checking their personal Gmail account because they confused the Tor browser with their regular Firefox. All it takes is one mistake.

Or another stupid thing: lack of separation between their online and offline personae. Using a bitcoin wallet, funded with their regular bank account, making withdrawals to an account in their name (because they thought that BTC is "anonymous" and "untraceable").

Sounds so silly and yet this happens. Criminals get caught because they are dumb, careless and sometimes unlucky. It's not the because the police have magic powers.

Online crime is not just fought online but offline. Police resort to controlled purchases and classic infiltration techniques eg: buy stuff like weed, preferably from someone trusted in the community, a mod or someone high-up. Then trace the packages, figure out their shipping patterns, obtain camera footage. Identify the guy. Find the guy. Arrest the guy. Move up the chain. Get closer to the admins.

  I also don't get how dark markets and child porn still exists on onion
  sites if all it takes is a little bit of cooperation to de-anonymize
  everyone?

A couple reasons among many:

Many countries actually have established channels and cooperate on law enforcement issues, but not all countries are interested in cooperating with each other especially when they are adversaries
Many countries governments are corrupt to some degree, some engage in criminal activity for financial gain
Law enforcement agencies (LEA) do not have the time and resources to go after every offender, so they have to prioritize targets. When your darkmarket is regularly mentioned in the news, then assume it is already under investigation and possibly infiltrated. You have probably noticed that nearly every darkmarket ends up doing an exit scam and disappears. So you could say justice is already meted out without intervention from the authorities.
LEA take their time: rather than shut down an illegal operation outright they could watch the action and wait to catch more offenders. Consider for example the case of Hansa:
Operation Bayonet: Inside the Sting That Hijacked an Entire Dark Web Drug Market. Everything takes time.

The conclusion is that no system can be guaranteed to be foolproof but can nonetheless thwart the efforts of adversaries to unmask you. If you are a wanted person Tor should not be the sole security layer, but a component in your personal strategy and you still need good opsec. Tor does not protect against human mistakes and stupidity, this is beyond the scope of the project.


How will SHA1 deprecation affect internal CA's? I am hearing that the SHA1 Deprecation notices from MS/CHROME only apply to certs that are a part of a public trusted root program. This makes one believe that IE will have new logic built in to allow it to distinguish certs issued by internal CA's as opposed to certs issued by Public CA's and NOT flag sites as unsafe that are deemed to be SHA1 internal?

So the way I see it is its kind of pointless to leave SHA1 legacy copies of certs in the trusted root store as a fallback if the browser is going to flag all SHA1 certs as unsafe anyway. Unless you are simply going for connectivity for legacy platforms that can't use SHA2 and don't care about warnings.

Thoughts?

Microsoft has had the logic in place for some time.

By default, any certificate that is a subordinate of a trust anchor from the Microsoft Trusted Root Program will not be trusted after the cut-off date if the subordinate has a SHA1 signature.  Any SHA1 certificate that is a subordinate of a locally installed trust anchor will still be trusted.  This is the case for all applications that use Microsoft's built in CAPI for their certificate processing, which includes Internet Explorer and later versions of Chrome.

Mozilla decided to do their own thing with the Firefox browser (as it doesn't use CAPI) and stopped trusting any SHA1 certificates, regardless of whether the trust anchor is internal or part of the Mozilla Trusted Root Program.

Remember that all trust anchors are trusted because you (or the browser/OS developers) explicitly placed them in the trust anchor store and not because they are digitally signed.  Therefore, whether the trust anchor certificate has a SHA512, SHA1 or MD4 signature makes no difference whatsoever - the signature is not used to imply any trust or security in the certificate.


What are the potential risks of performing DNS queries on unknown domains? When investigating malicious domains that are used for phishing, malware, etc, you often have to issue DNS queries for these domains.

For example:

dig @1.1.1.1 example.com

The potential risks of issuing this command are:

A maliciously crafted DNS record could try to exploit my DNS utility
A maliciously crafted DNS record could try to exploit my terminal
The DNS zone I am querying could be delegated to another, potentially malicious DNS server
Possible privacy violations[?]

Are there any other potential risks that I have missed or considerations that I should make?

Do you think that this is a valid concern?

Remember back when CVE-2015-7547 was disclosed by Google and RedHat? It was a high risk DNS security flaw that had gone undetected for years. It is unclear whether the issue had been exploited "in the wild" before then. DNS flaws are a real issue and you should consider it when querying random domain names.

When investigating suspicious domain names such as phishing and malware load them in a Virtual Machine - there is always the risk that untrusted code / data might compromise your system - consider your threat model and protect against it - let it be a throw-away one rather than your primary one.

Hope this helps :)


A store I visited is breaching PCI DSS. What should I do? I recently visited a store in Northern Ireland and paid using my Visa debit card. The receipt shows my entire card number and expiry date. It also contains other info. I thought this should all be crossed out as now they have a copy of my card number and details which was not encrypted or hidden.

Printing full PAN and expiry date on the customer receipt is a violation of Visa's requirements listed in "Card Acceptance Guidelines for Visa Merchants". Therefore I suggest you to submit merchant violation complaint form directly to Visa. It is located here: https://usa.visa.com/Forms/merchant-violation-complaint-form.html


What exactly does ipsec and ssl do? Im trying to figure out how SSL and ipsec works. I know the process in both SSL and ipsec but why do I need SSL if I can use IPsec when it runs below the transport layer. Wont IPsec encrypt everything ssl does?

*What is the difference between the level of security provided by IPsec and SSL?
If I use IPsec is SSL necessary?
Is encryption only during transmission for both IPserc and SSL?
if not what services are used for local encryption? SOA web services?

PS: Ive read how the different protocols work at an encryption level but I have a hard time understanding the big picture.

Thanks.

IPsec: Commonly used in VPNs, it supports several means of authentication, but requires some coordination between the endpoints to choose keys, root CA's or other authentication methods.

It can run in two modes: tunnel mode, where the entire packet is encrypted and encapsulated in an IPsec tunnel packet header, or transport mode, with only the data section of the packet encrypted. VPNs use tunnel mode.

SSL: Used for client-server communications because it requires no coordination between parties.

No need to use both on the same connection.

See this question for more details: Are there any reasons for using SSL over IPSec?


Is Payment using an iframe more secure than using as Javascript library? Traditionally most Payment providers only provide Hosted Payment Sites via redirect or iframe. But now an increasing number is also supporting payment integration via a Javascript library.

I imagine the case in which an attacker is able to inject code into the Web App: the attacker would still not be able to read the iframe's content because of Same-origin policy. On the other hand in the JS lib case, a jQuery 1-liner is enough to send the user's credit card data to some server.

Is this view correct? Or are both options equally safe, because once an attacker can inject code, he could do (almost) anything anyway?

Although the same-origin policy may stop an attacker from accessing the legitimate iFrame content, the problem is that the user has no way to verify that they're actually interacting with the legitimate iFrame (short of going to the source which most users won't do). An attacker could just as easily replace the iFrame source with a phishing page and gain the users credit card details that way.

Both iFrame and JS based gateways are vulnerable to approximately the same issues, so I would argue that they're both equally insecure compared hosted gateways. The benefits of hosted gateways are that:

The user can verify the URL to be sure who they're interacting with
The user can validate the SSL/TLS certificate and encryption to be even more sure about who they're interacting with
A payment gateway operated by a bank is most likely better tested for vulnerabilities than some arbitrary site.
Users can be reasonably confident in the integrity of their payment details if the totals, etc. are displayed by the external gateway. Compared to onsite where the site may say they'll charge you one thing then charge you another.

On the other hand, transferring users to an external payment gateway is considered a bad user experience and interfacing with a payment processor securely on the server side is complicated, so compromises are made and these JS based gateways are becoming popular.


Is PCI SAQ A or A-EP applicable for my use case? I read the FAQ over here andI feel that we do not need to be PCI Compliance but I have read many other posts, articles etc which seem to contradict my assumption. So I was wondering if any of you guys can throw some light on it. Here is my use case,

We are a subscription based platform, so basically we charge users on a recurring basis once they sign up.

We currently use Stripe, PayPal & Amazon Payments as our Payment Processors. While using these services we never store, process or transmit cardholder data through out servers.

For PayPal there is a complete re-direct to their pages for login & approval.
For Amazon Payments a JavaScript widget is used to login to Amazon account (provided by Amazon itself) and grant us the approval.
For Stripe, we use their Checkout widget to do the complete CC processing. We just get the token at the end of it.

It is kind of confusing trying to figure it out the required level of PCI compliance if any. If we were to be required for PCI compliance then there is further confusion as to whether SAQ A or SAQ A-EP is applicable to us.

UPDATE

Looks like at least using Stripe we are good with having just SAQ A per their customer support.

Short version:

You seem to be A-EP You seem to be A, based on the specific products referenced, but you should ask your processor(s) to be sure.

If by "Amazon Payments JavaScript widget" you mean Amazon Express Checkout, then you're SAQ A-EP, because "elements of the payment page originate from the merchant website".

Amazon Payments "Login and Pay" is jut a button that takes the processors site, and the entire payment is carried out on the processors site, so technically there are no "elements of the payment page (that) originate from the merchant website" - the payment page is all on Amazon, none on your site.  So that should also be SAQ A, although it would be really nice if Amazon put this in their FAQ.

Mind you, the distinction between a link that sends customers to the processors site and a link that cites an iframe on the processors site and a link that uses direct post or javascript requests to send card data to the processors site are, in security terms, completely equivalent.  In all cases, an attacker who compromises the merchant's web server can affect where the customer sends their card data.  The only significant difference is that the customer can see the processor's URL in their address bar with something like "Login and Pay", and we assume people check that and know not to perform Amazon payments with aamazon.ru, even if it has a valid certificate.

Or - in short - if this is confusing to you, it's because it's confusing.  Again, best to ask your processor.  They're supposed to know better.

If by "Stripe Checkout widget" you mean Checkout, then you're SAQ A-EP, because "elements of the payment page originate from the merchant website."

According to Stripe, even though Checkout is a JavaScript widget "it already rests inside an iframe controlled by Stripe, you can continue to fill out SAQ A." (emphasis mine)

You would only seem to be SAQ A because all your checkout forms were hosted by the processors and your customers were directed to them before checkout or via an iframe .

Long version:

The key distinction here is found in page iii of the SAQ A:

  The entirety of all payment pages delivered to the consumer’s browser originates directly from a third-party PCI DSS validated service provider(s)

If your processors all get invoked via an iframe, then you probably meet this requirement.  But if their "javascript widget" or "checkout widget" are served from your servers, then you fall into SAQ A-EP instead.  Your processors, of course, should be able to tell which they are.

The fact that the word "Javascript widget" shows up here suggests to me you're A-EP, but I'm not familiar enough with Amazon or Stripe's offerings to really know.  And, honestly, you're not really expected to know the difference - they are.

The full set of expectations for a SAQ A merchant to meet are as follows:

  SAQ A merchants may be either e-commerce or mail/telephone-order merchants (card-not-present), and do not store, process, or transmit any cardholder data in electronic format on their systems or premises.

  SAQ A merchants confirm that, for this payment channel:

  Your company accepts only card-not-present (e-commerce or mail/telephone-order) transactions;
  All payment acceptance and processing are entirely outsourced to PCI DSS validated third-party service providers;
  Your company has no direct control of the manner in which cardholder data is captured, processed, transmitted, or stored;
  Your company does not electronically store, process, or transmit any cardholder data on your systems or premises, but relies entirely
  on a third party(s) to handle all these functions;
  Your company has confirmed that all third party(s) handling acceptance, storage, processing, and/or transmission of cardholder
  data are PCI DSS compliant; and
  Your company retains only paper reports or receipts with cardholder data, and these documents are not received electronically.

  Additionally, for e-commerce channels:

  The entirety of all payment pages delivered to the consumer’s browser originates directly from a third-party PCI DSS validated
  service provider(s).


Revoke OAuth2 Token For Mobile App When a user logs into my mobile app it uses OAuth to authenticate them and generates a token. The token is then checked against each subsequent request. Each user account in my application has an active flag. When I deactivate an account I set this flag to False which is checked on login, if False the user will not be able to login and will not receive an authentication token.

However, I have to cover the scenario where a mobile device could be misplaced while the user still has a valid token. So someone who should not see data now has access to it. I can deactivate the user account but with an existing valid token the user would still be able to use the app until it expires.

Is there a way to force token expiration for a certain user?
Do I have to store the tokens in a database to be able to achieve this?

You cannot force token expiration. Tokens expire when its lifetime (determined when constructed) has passed.

You can distribute a blacklist to the points in your system where they are checked (eg api server for remote resource or the app for a local resource) to enable you to revoke them. If your token contains the userId you can distribute a blacklist of userIds and just check if it is on the blacklist. If your tokens do not contain some kind of identifier you have to store the tokens you issue for each user until they expire and distribute a blacklist of tokens.

You could also choose to give your tokens a very short livetime and just wait for them to expire.


Facebook account keeps getting hacked, can't seem to figure out why or how? One of my friends, she has a lot of friends on Facebook, and uses it for marketing.

Her account keeps getting broken into. Her password gets reset and/or gets locked for changing resetting password too many times.

So basically, what happens is this one user/virus/trojan whatever somehow manages to request a password reset.  Then it adds its own email address to the account.

As far as I can tell, that user has not posted anything on Facebook nor have they messaged anyone. So their purpose is unknown.

What we've done to recover from this hasn't helped.  We tried:

Changing the email address to something completely new and unguessable.  We also removed all the current email addresses so they can't use those addresses to run through recovery again.
Removing the phone number.
Changing security questions.
Enabling HTTPS only.
Changing password to something generated using a random password generator.
Reseting the password on the email address she uses (it's a Gmail account).
Completely wiping her laptop which had Windows Vista and installing Windows 7.
Asking her not to use any of the PC's at work to log into Facebook.
Removing any Facebook apps that I don't recognize, or aren't needed.

I'm completely stumped at how this keeps happening.

I don't think its a "person"; it's probably a virus of some kind.  Which is why I wiped the computer she uses.  Now, though, I'm not so sure.

Any ideas?

EDIT: Removed all FB apps part added to list

It's very likely that the person who owns the account uses a Facebook App that has malicious code in it, as all these issues here can be cause by said malicious Facebook app. (Note: this was stated in comments several times, so I posted this as an answer).

To fix this, the user should remove all access for apps to his/her Facebook account.  Then subsequently either not use apps, or very selectively use apps.  Then, the user should run malware checks on their system (MalwareBytes would be one such system).  Then, the user, after ensuring his/her system is clean, should change the email address and the password on their Facebook account. But that should only be done once they've removed apps access to their account and made certain their system has no malware on it (is "clean").


Does an editable file owned by root pose any risk? On a Linux machine, if we allowed the user bob with home directory /home/bob to put any content (malicious or not) into the file /home/bob/dangerfile.txt

-rw-r--r-- 1 root root  61K Aug 24 13:59 dangerfile.txt

Would this pose any security risk? Assuming that bob is not a root user, it seems like the only risk would be filling up the disk space if there wasn't a quota.

Motivation: In setting up a Docker container, I noticed that if you mapped a local volume, the resulting files would root:root since they were created by the Docker daemon. Ignoring the other security shortcomings of Docker for the time, this question asks if dangerfile.txt poses any risk to the system.

I think it highly unlikely this would represent any risk. Even if dangerfile.txt were executable, it would still be executed as bob and lack the ability to do root-like things.


Do keyfiles actually add any meaningful security in the presence of strong passwords? In the context of protecting access to local encrypted files or devices against a determined (and competent) adversary, is there any reason to believe that the use of a key file actually presents a significant hurdle that a strong (pseudo-random, long) password does not?

I've been using them myself for a while as a poor-man's two-factor authentication scheme, but after reading some of the recent security news, I'm starting to wonder if they actually add any meaningful value - so I did some quick math, and the more I look into it, the less convinced I am that they add any value against anyone with more resources or talent than a simple script kiddie.  The more I think about it, the more I think that anyone who could crack or otherwise obtain one of the very long passwords I use to encrypt files or drives isn't going to have any difficulty getting their hands on my keyfiles, and determining the keyfiles from the rest would be possible with a brute-force attack and a good GPU rig.

As far as the math goes, a 20 character, psuedorandom password containing the 4 standard character sets yields 9520 or 3.58*1039 possibilities, which is a little more than 10 times better than 128 bits of entropy (which would yield 3.40*1038 possibilities).  In order to get a similar degree of entropy with keyfiles, I'd need to select 9 files from a list of 100,000 if the order doesn't matter (2.75*1039 possibilities) or 8 files from a list of 100,000 if the order does matter (9.997*1039 possibilities).

Even ignoring the practical difficulty obtaining and maintaining such a large list of static files that could serve as potential keyfiles, and obscuring which ones are the actual files in question, it seems to me like the keyfile approach requires more effort than committing another ~20 random characters to memory.

The only advantage I can see from using keyfiles would be in protection against a keylogger... from 10 years ago.  They come with screen capture capabilities these days, and I don't imagine that someone who can get malicious code onto a given machine would be unable to copy the keyfiles when they were accessed for authentication purposes, even if they were offline and completely physically inaccessible the rest of the time.

So, am I missing something, doing the math wrong, or are keyfiles not effective as a second authentication factor in respect to a determined adversary, and local encryption protected by secure passwords?

Yes, keyfiles add some security. That added security may or may not be useful depending on the circumstances, but it's there.

A (properly randomly generated) keyfile has at least 128 bits of entropy. That's a lot more than a decently memorable password. With proper hashing, a long enough but still memorable password cannot be cracked in a reasonable time at a reasonable cost. However a keyfile is more future-proof than a memorable password.

More importantly, combining a password with a keyfile means that you have two authentication factors. (That's assuming you type the password rather than storing it in a file on the same machine, otherwise the password and the keyfile play the same role.) A password is “something you know”, whereas a keyfile is “something you have” — you have the storage media containing the password.

Multi-factor authentication is useful because different factors are subject to different threats. Malware running on the machine where you use the credentials is the worst case scenario: it can snoop on any credential you enter in any way whatsoever — and it can impersonate or subvert the application anyway, so you've lost regardless of what happens to your credentials. Many other attacks only affect one vector. For example, an attacker who steals backup tapes can obtain the keyfile but not the password. Conversely, there are many attacks that can reveal a password but not a keyfile, such as an shoulder surfing (possibly helped by a camera), or a hardware keylogger, or any other form of physical snooping (e.g. through sound or radio emissions).


What is the difference between full end-to-end encryption and end-to-end encryption? What is the difference between full end-to-end encryption and end-to-end encryption?

Are there any differences between these two terms?

There is no difference. End-to-end encryption simply means that both endpoints share a secret key which is used to encrypt all traffic between them. There is no difference between "full" end-to-end encryption and end-to-end encryption. It's like the (lack of) difference between forward secrecy and perfect forward secrecy. They're just different terms to explain the exact same concept.


How to securely get a key from a key server? In the installation procedure of Gentoo, there is a step to check signature of the downloaded iso file. To do so, we first need to download the set of keys from a key server:
$ gpg --keyserver hkps://hkps.pool.sks-keyservers.net --recv-keys 0xBB572E0E2D182910

However, when I first run this command, I got the following error:
$ gpg --keyserver hkps://hkps.pool.sks-keyservers.net --recv-keys 0xBB572E0E2D182910
gpg: requesting key 2D182910 from hkps server hkps.pool.sks-keyservers.net
gpgkeys: HTTP fetch error 60: server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none

If I correctly understand this error, that means gpg can't trust the CA that emitted the certificate of the key server. To fix this issue, I need to add the certificate of the CA to my list of trusted certificates.
The question is: how can I get this certificate in a safely manner? By safe, I mean the certificate can't be compromised by a man-in-the-middle attack, for instance.
Using openssl, I can see the certificate of the key server is signed by sks-keyservers.net:
$ openssl s_client -showcerts -connect hkps.pool.sks-keyservers.net:443
CONNECTED(00000005)
depth=1 C = NO, ST = Oslo, O = sks-keyservers.net CA, CN = sks-keyservers.net CA
verify error:num=19:self signed certificate in certificate chain

But how can I trust the certificate given by this command? How can I be sure no attacker falsified the anwser?

They publish their CA certificate on their website. Verify that you are accessing it securely (HTTPS with no errors), then download it. You can also verify its signature and fingerprint (all listed).
They also have instructions to tell gpg to use a local CA to verify the connection:

hkps.pool.sks-keyservers.net
This is a pool containing only servers
available using hkps. Regular A and AAAA and SRV records are included
for port 443 servers, and a lookup is performed for _pgpkey-https._tcp
on the individual servers to determine if a hkps enabled service is
listening on another port. At this point, however, servers not running
on port 443 are not included.
This pool only include servers that have been certified by the
sks-keyservers.net CA, of which the certificate can be found at
https://sks-keyservers.net/sks-keyservers.netCA.pem [OpenPGP
signature] [CRL].
For GnuPG 1.4 and 2.0 installations this can be used by using the
following parameters in gpg.conf:
~/.gnupg/gpg.conf:
  keyserver hkps://hkps.pool.sks-keyservers.net
  keyserver-options ca-cert-file=/path/to/CA/sks-keyservers.netCA.pem

GnuPG 2.1 users prior to version 2.1.11 (starting with this version
the certificate is enabled by default for this pool) want to add the
following in dirmngr.conf:
~/.gnupg/dirmngr.conf:
   hkp-cacert
   /path/to/CA/sks-keyservers.netCA.pem


Can HTTPS server configured without a server certificate? I have noticed that, a HTTPS connection can be set up with the server configured to use a certificate, and when additional security is required, the server can ask the client to provide a client certificate, validate it and set up connection.

It seems that, if we ask all clients to provide their certificates, which contains public keys and corresponding signatures, the secure connection should also able to be established. The server just validates the signatures, then encrypts the data being send using client's public key. If knowledge of the identity of clients is more important than that of the server, the server certificate is of no use here.

So is it supported in HTTPS protocol, that the server provides no certificates but ask for client certificates, and then establish HTTPS connection?

HTTPS is HTTP-within-SSL. SSL is a tunnel protocol: it works over an existing bidirectional stream for data, and provides a bidirectional stream for data. The two parties involved in SSL are the client and the server, which are two roles within the SSL protocol; it is not required that these roles map to the notions of "client" and "server" of the underlying transport protocol.

For instance, a setup can be imagined, in which the client system (C) initiates a TCP connection to the server (S), and then the server initiates a SSL handshake, acting as the SSL client (i.e. sending the ClientHello message, instead of waiting for an incoming ClientHello). This reverses the roles of both machines, and also the security guarantees: the machine S will have a good idea of the identity of the connected client C, but the client C will not be sure of what server S it is talking to (an attacker could have intercepted and redirected the communication). Depending on the context, this may or may not be appropriate.

However, this departs from HTTPS, in which the TCP client is also the SSL client, and that client expects the server to show a certificate, which the client will validate against its known, trusted CA, and which contains the expected server name (as extracted from the URL, see section 3.1). Correspondingly, existing clients (Web browser) do not support reversal of SSL roles. If your situation calls for using browsers, then you must, of course, use only the functionality available in browsers.

SSL does support a few certificate-less cipher suites. The "DH_anon" cipher suites are deemed weak, because they imply no authentication at all (thus, Man-in-the-Middle attacks are possible). The PSK cipher suites imply mutual authentication of both client and server with regards to a shared secret. When the shared secret is of low entropy (say, it is a password), SRP cipher suites are better.

There again, these cipher suites are not (yet) available in mainstream browsers (although some people are working on it). They require a shared secret (key or password), a condition which may or may not be easy to achieve in your specific context.

If knowledge of the server identity is unimportant, then you can give the server a self-signed certificate, along with instructions for clients on how to make their browser accept the server certificate without cringing too loudly (see this question as a starting point). This will map to "normal SSL", which has two benefits:

Existing browsers support that.
When the server presents a certificate, however bogus, it is then allowed to ask, in return, for a client certificate, yielding the kind of authentication that you are looking for. And Web browsers do support client certificates for SSL.

Note that the self-signed certificate contains the server public key. Though this public key won't be validated, it will still be used to power the key exchange, so you must use an appropriate key type and length (say, RSA 2048). Alternatively, use one of the "DHE" cipher suites, in which case the server public key is used only for signatures, not to actually protect the data, so (in your specific case), its size and secrecy becomes unimportant.


Is "Small HTTP server" malware? I have used Small HTTP server in the past, years ago. I went to its website do download it again, but it has a dubious WOT rating: some say it is malware, some say it isn't.

I proceeded to check it on VirusTotal, where it got 20 positive identifications. Out of those 20, 8 list it as "SmallHTTP" or "Server Web", a little uninformative to me. One say it is "riskware", while Ikarus and Kaspersky list it as "not-a-virus:Server-Web.Win32.SmallHTTP".

However, six other tools identify it with words such as "Backdoor", "malware", "trojan", etc.

ClamAv says it is a "Possibly Unwanted Application. While not necessarily malicious, the scanned file presents certain characteristics which depending on the user policies and environment may or may not represent a threat".

Is there any way to check if it is really malware?

It is probable that some malware included a copy of this HTTP server, or some code which looks like this HTTP server, in order to, say, run a HTTP server on the infected machine. Being able to host parasitic servers on infected hosts is one of the goals of malware, and a lightweight HTTP server code (both in code size and RAM footprint) would be more appropriate for that than a heavyweight Apache or IIS, which would be much harder to smuggle in an email Trojan.

Now of course you cannot really know whether any given piece of software is malicious or not. In fact it is not fully defined: if a server code has a remotely exploitable bug, then it could be used a backdoor for attackers. Whether this bug is malicious or not depends on the intent of the software writer: was he aware of the bug ? It won't change a bit in the code, though.

With opensource software you could try to run your own audit of the code, which will be hard work and does not guarantee that all holes will be found (otherwise, we would know how to produce code without bugs), but that's better than nothing.


How to deal with a person who gets easily fooled by internet and mail scams? alternative title: How to deal with a person who has gotten paranoid and doesn't want to go online anymore?

A person, who has over the years been scammed many times, by bad spam/fraud emails, and sites' spyware/ad-ware/..etc that do popup ads like "click here to scan your pc for free !!!" , usually ends with bad virus, and antivirus can't be enabled anymore, and requiring full windows re-install.

How to actually make his internet more secure?, so that he can use his computer to go online and not worry about repercussions?

I was thinking of putting an ubuntu on a flash drive (or using wubi installer) and let him use that as a boot drive for internet, but being not very technically proficient might result in more trouble ..

Are there any other options?

It all depends on the person; but a good first step would be to change their default browser to Chrome or Firefox - install AdBlock Plus (http://adblockplus.org/, or similar) and Ghostery (http://www.ghostery.com/) in their browser, and a decent anti-virus (Microsoft Security Essentials (http://www.microsoft.com/mse) should be fine, and since it's free - you don't risk them just not renewing). Install Soluto (https://www.soluto.com/home) and keep an eye on any changes to default browser, etc.

Turn on auto-updating for everything, Windows, your browser, Flash, Java, etc.

Make sure UAC is on, if they like to just click through the prompts, make them non-admin and set up an admin password - that way they have to enter it to do anything and you should print that on a bit of paper under the words "THIS MAY NOT BE A GOOD IDEA".

Now, a slightly controversial one, disabling Internet Explorer: on their machine, go Start/Run and enter 'gpedit.msc', navigate to Computer Configuration / Windows Settings / Security Settings / Software Restriction Policies / right click that and choose 'New Software Restriction Policy' and then under additional rules, right click, New Path Rule and enter 'c:\Program Files\Internet Explorer\iexplore.exe', make sure it's set to Disallowed.

Going extreme (with a key, etc.) is going to be a hassle - you want the experience to be something familiar. The Group Policy edit is to prevent them bypassing Adblock or Ghostery unwittingly.

That should make it largely worry-free. Soluto should give you the ability to remotely install TeamViewer or whatever and remote in if something goes wrong, but that should cover most malware entry points.


Does publishing the md5sum of a private key compromise the private key in any meaningful way? If I have a 4096 DSA private key used for signing binaries, and I want to ensure that a partner has an identical server using the same private key, can I send the md5sum of the private keys over an insecure channel to verify this, without meaningfully compromising the key?

That is, would publishing an md5sum of the private key make it feasible for an attacker to generate a valid signature for an unauthorised binary?

You can use the MD5 cryptography hash without any serious concern but why not consider using the public key to confirm the private key in question.

You could have the partner sign a sample binary and use the public key to confirm the signature and thereby confirm the private key.

If you want to work outside the signing infrastructure you could use a PKI utility like openssl to confirm the key set using the partner's private key and the public key.


what does it mean to be setuid root? I am reading Tanenbaum's Modern Operating Systems 3e. He says "Suppose that the program being attacked [with malicious code] is SETUID root in UNIX (or has Administrator power in Windows). The [malicious code inserted with a buffer overflow attack] can now make a couple of system calls to convert the attacker's shell file on the disk into SETUID root, so that when it is executed it has superuser power."

What does it mean to be SETUID root? Does he mean that the program has root permissions? Why does he say that the program is setuid root?

This somewhat of a language question, but to a security noob with only basic linux/unix that passage in the book is hard to understand. What's he talking about?

SETUID means that the executable can run under different permissions than the user who has executed it.

Certain applications are set like this so the users can run with low permissions but a specific application they need to run with higher permissions can be.

SETUID 0 or root means that when the program is run it is as if root ran it - which leaves you open to all the usual security risks of running something at high permission levels - it could potentially do anything to your system - so generally the number of applications that require SETUID should be minimised on a Unix box. Most security audits of Unix machines include looking for SETUID and SETGID files that are world writeable as they present a high risk.


Is there a way to give out secure tickets wihout storing them? I'm building a website on which I want to make it very easy for users to create pages anonymously and later be able to come back and edit those pages. One way to do so is to give out confidential tickets which are derived from the page ID to those users when they create the page. Later I would be able to derive the page ID from the ticket and allow a user in possession of the ticket to edit that page.

Of course this needs to be secure, so: 1) third parties shouldn't be able to derive the page ID from a given ticket, and even more importantly: 2) third parties should not be able to predict the ticket for a given page ID.

I could of course easily do this by randomly generating the tickets and storing them in a database, however I would like to try and do this without having to store the tickets.

In other words I'm looking for something like this:

Let A be a unique public page ID.
Let S be some kind of unchanging master key or other secret I possess and don't give out.
Using S, transform A to B, such that I can later transform B back to A, but someone not in possession of S cannot.
It should not be possible, or be very hard, to derive S even if you have a large collection of A-B pairs.

Does such a process exist? One thing I thought of is a simple XOR, however that would be easy to crack with just a few examples of A-B pairs. I can't use a hash, because they are intentionally irreversible; I can't derive A from B if B is a hash of A.

This sounds like the perfect use of an HMAC. You create a secure random secret S. Then the ticket for each page will be ID + HMAC(S, ID). When you get a ticket you extract the ID, redo the HMAC and then compare your result with that in the ticket.

While this is likely be simpler and faster than an encryption solution, it will only work if you don't mind ID being in clear-text in the ticket.


Should I implement incorrect password delay in a website or a webservice? With arguments expressed in this answer, there is a few seconds delay between user enters an incorrect password and when he/she actually learns, that password was incorrect. This security solution is implemented in an operating system (here an elementary OS) and in console commands like sudo etc.

Should I implement the same mechanism in my website or web service? Or may I easily assume, that a typical delays in exchanging information between browser and server will be enough to block bloated brute-force attacts (in takes more than one second even on local system between pushing Login button on my site until an information about an incorrect password is returned; this seems enough long AFAIK).

There is a similar question on this matter. However, both answers (this and this) are not satisfying my question or are even a bit off-topic. I'm not asking about suspension or temporal locking of user account after each failed login (and thus arguments about locking attacker preventing real user from login are off). I'm talking only about possible delay between displaying login form again.

I assume that your intention with the failure delay is to prevent brute force attacks: if an attacker is trying to guess a user's password, she will first fail many times; if we can make those failures take a substantial amount of time longer, then it will make the attack an order of magnitude harder, and thus unlikely to succeed (in a reasonable time frame).

However.

This assumes that the attacker waits patiently between login attempts. And, as we all know, cyberhackers are a very polite and patient folk.
That said, some attackers may choose NOT to wait, and simply send many requests in parallel. If a login attempt doesn't receive a response immediately, the attacker can interpret that as a failed attempt, kill that request, and move on the next one.

An extra benefit of this scheme is that it would be that much easier for an attacker to create unreasonable load on the server (just send a lot of failing login requests, each one will occupy a thread for several seconds...), and possibly even succeed in DoSing the server.

In fact, the main problem with this solution is that it precisely does NOT prevent many parallel requests. If an attacker is attempting an online brute force attack, she is not going to sit in front of the keyboard typing in many passwords, one after the other, as fast as Hugh Jackman possibly can - if that was the case, you would only be at risk if the user has a dead simple password.
In reality, she will have a script or automated tool send (almost) as many requests as the server can handle, and then keep going. The risk is not that someone will try 30 different passwords a minute, it's 1000 passwords a minute, or 10,000.

The only way to prevent that is user throttling / account lockout / incremental suspension - call it what you will, this is all basically the same idea of allowing X number of login attempts per account within a given timeframe.
So even though this doesn't cut down to "a single login attempt at a time", it does get close enough.


Accepting an untrusted security certificate? What is the risk of accepting an untrusted site security certificate in your browser if you're not entering any data, but merely browsing the site?

X.509 security certificates are mainly about the authentication of the site providing it, i.e. you know the site is really the site it claims to be. This is why e.g. banks use certificates at a high trust level (which means they are signed by more certification authorities, signed by more established cas rather than unknown ones, etc.).
Even without providing any data, with untrusted certificates, you have the risk of becoming a victim of a man-in-the-middle attack or phishing, where someone tries to either modify or spoof the site you're visting. This way, you might get false information, which can do in certain cases as much harm as stealing your credentials.