How does the same-origin policy apply between browser tabs? Let's assume that we have 2 open tabs in a browser containing page A (A.html, A.js) into the first tab and page B (B.html, B.js) into the second tab and that page A and B have the same origin (scheme, domain, port).

Can A.js call a function from B.js?
Can A.js modify the DOM of page B.html?

Can A.js call a function from B.js?

No, the javascript need to be defined on your current page

  Can A.js modify the DOM of page B.html?

Yes, but you need a reference AND have the same origin.

If page A have a reference to page B, it is possible for A to modify the DOM in B.

Page A can have a reference to page B if page A opened page B and saved the reference. Also page B can access page A via the opener property. You can open a new tab/page in javascript with the following code :

// Open a new window
var myWindow = window.open("", "myWindow", "width=200, height=100");

// Write some text in the new window
myWindow.document.write("
This is 'myWindow'
");

// Write some text in the window that created the new window
myWindow.opener.document.write("
This is the source window!
");

Same Origin Policy Limitation

The same origin policy limit what you can access. If the 2 pages are on different domains, you will not be able to access the window.document property to read or write. Here is a list of what you can access when the other page is from a different domain.


Good publicly available unpredictable random number sources? I wasn't sure whether to ask this on crypto or security, but since it involves real-world trust and services, I figured this is the better place.

Consider that me and my friends (whom for the purposes of this question I do not trust) want to lock in a random number that only becomes available at a future date. This could be for example to meet in a random place in a country without being able to set up and investigate the area ahead of time.

It's important that the random number is:

Not knowable before the agreed upon date and time.
Not possible to influence.
Sufficiently random (hash high entropy).

As an example scheme, we could choose the random number to be the hash of the headline of a major newspaper from our chosen date. Barring incredibly extreme measures, this is not knowable, impossible to influence, but has relatively low entropy.

A better scheme might be to choose weather data from an agreed upon source. But there an attack vector hacking the weather station might be more reasonable than influencing the headline of a public newspaper. Or tracking down sensors and messing with those.

What are some good, publicly available, granular (e.g. each hour is better than each day) sources of unknowable, impossible to influence, sufficiently random numbers?

The top article on the newspaper website really might be what you want as your entropy source. This means that you can use the hash of an article:

entropy source: top article of newspaper site
length of random number (e.g. SHA256->256Bit or AES-OFB as your stream cipher)
Secret: If you fear a third party attack you should keep secret which newspaper you use and choose the newspaper randomly with your partners

Cons:

One of your partners could write a script which always shows him the current position generated by the article
The top article might change before your partners have calculated the random number

Old answer

This isn't exactly what you asked for, but it might match your use-case.

Shamir's Secret Sharing

If you need the following conditions to be met:

You don't trust the persons
All persons need to be in a room/or communicating with each other on that day to get the secret

I would suggest using Shamir's Secret Sharing Scheme:
https://en.wikipedia.org/wiki/Shamir's_Secret_Sharing

With SSS you can split a secret in multiple pieces e.g. 5 pieces and hand it out to 4 persons (you keep one for yourself).
Only if all 5 pieces are together, you can reconstruct the secret.

You may also compute SSS to make it possible that e.g. only 3/5 pieces are needed to get the secret.


Citation Needed for FIPS Anecdote Regarding MD5 and RC4 I've heard it mentioned many times by colleagues and other information security professionals that it is a violation of Federal Information Processing Standards (FIPS) regulations for an internet-facing web server to accept cipher suites containing the MD5 or RC4 algorithms, during the server's SSL or TLS negotiation process.

I know that there are others which are also disallowed, but I haven't been able to find a citation anywhere in the authoritative literature that flat-out says "MD5, RC4, ... are not allowed". Note that the context of use is within a federal information system; hence, compliance with FIPS regulations is rather mandatory, and not simply advisory as it would be for a commercial organization.

In order to help my organization understand that there may be a regulatory compliance issue, I would like someone to point me to literature from NIST (or whichever other organization created/enforces FIPS) specifically blacklisting the use of MD5 and RC4 in the context of SSL connections to Federal information systems.

If it makes a difference, yes, the system may potentially need to handle personally identifiable information (PII), so any regulations contingent on that should be pointed out as well.

As some more info: I have been able to design a custom security tool that actually limits the advertised SSL cipher suites when it negotiates with the server. This allows me to test the server against a hypothetical client that does not accept more secure algorithms such as SHA1 for the message digest and RSA for the encryption. It goes without saying that, if there is a regulatory compliance issue, then it would easily override any concerns about compatibility with clients that don't support FIPS-compliant algorithms.

TLS is actually one of the rare instances where MD5 is, in fact, specifically stated as being allowed to be used for key agreement.  Citation is in the FIPS 140-2 IG, D.8 (pg. 157, point (e)(1).

SSLv3 use of MD5 is disallowed due to a difference in how MD5 is used.  See footnote 2 at the bottom of page 160 of the same IG:

The problem with SSL 3.0 is the key derivation process that applies to all SSL 3.0 cipher suites: half of the master key that is set up during the SSL key exchange depends entirely on the MD5 hash function. MD5 is not an approved algorithm, and its collision resistance property has been broken by Antoine Joux.
TLS also uses MD5 in the key derivation process, but in a different manner, so that all of the master key depends on both MD5 and SHA-1; nothing in TLS actually depends on MD5 for its security.
Therefore, TLS implementations can be validated under FIPS 140-2, while SSL 3.0 implementations cannot. TLS is version 3.1 of SSL, and most current servers and clients are capable of doing both SSL 3.0 and TLS.

Finally, I am fairly certain that RC4 is completely disallowed. On page 33 of the IG, RC4 is explicitly listed as a non-approved algorithm.  No other caveats are made in the IG with respects to RC4 and I've not experienced any claims in my line of work that would indicate that it could be acceptable in any other circumstances.


Is it safe to include the IV at the end of a hash? I have a PHP function I have written that uses a 64 bit binary string and a random initialization vector to encode data using the following basic principal:

$encrypted = openssl_encrypt($data_to_encrypt, AES_256_CTR, $64bit_binary_string, 0, $iv);

Then in order for me to decrypt the message I have to know the IV so I tie this to the new hash with a colon separator:

$encrypted = $encrypted . ':' . $iv;

Finally, I base64 encode the entire thing for another purpose

I have read that the IV does not need to be secret as long as it is random.  If this is true then am I correct in assuming that it is safe to be included at the end of the hash like this? Obviously, base64 is easy to reverse so once that has been done, I assume it would be easy for anyone to guess what the IV is. The problem would be decoding the 64bit string.

The IV is not secret so it doesn't matter how you store it. It's perfectly find to append it to a hash.


PKI/Why does Microsoft require my cert before encrypting an email? Microsoft doesn't allow sending public-key encrypted messages using Outlook 2003-2012 on Windows 7-8x environments without first creating your own Digital ID or private key for signing.

Per Microsoft, before encrypting an email to someone else, "it is required that both parties have valid digital certificates for email signing and encryption at the first place."  Why?  If I have someone's public key, why do I need to have my own - valid or invalid - certificate?  I am not signing the message, just encrypting it so that only the recipient can read it.

I think that sender's digital certificate is required since Outlook stores an encrypted copy of message on your side. Then you can open it with your own private key.


Can I do an enveloping XAdES signature on binary content? I need to sign some binary content (scanned documents) with a digital signature compliant with European norms, CAdES - XAdES. One option would be to use this library to do a XAdES signature. Is there a standard way of packaging binary content for inclusion in a XAdES enveloping signature? A developer in a hurry might Base64 encode the whole thing and put it in a pair of  tags? Seems a bit savage. Is there an accepted way? What about canonicalization? Can I just turn it off?

Base64 will add huge overhead so I would suggest one of the following solutions:

Sign the PDF but keep the XAdES signature in a separate XML file ("external signature"). The advantage is that the original document is instantly available even without the signature verification software. Which is also a security disadvantage, as people can open the file without verifying its authenticity. YMMV.
Rather than embedding PDF inside XAdES, embed XAdES inside PDF, as the format is very well prepared already for digital signatures since ISO 32000 and there's even a dedicated PDF profile for that called PAdES. It's the best solution by all factors as the signature will be validated automatically on document opening and you don't need dedicated software. And usability was always a huge problem in EU electronic signature, as documented in this article.


Known strings to have the same MD5 hash, not colliding in real life? I was reading this article about MD5 hash collisions in which it clearly states that these two strings (differences marked with ^):
d131dd02c5e6eec4693d9a0698aff95c2fcab58712467eab4004583eb8fb7f8955ad340609f4b30283e488832571415a085125e8f7cdc99fd91dbdf280373c5bd8823e3156348f5bae6dacd436c919c6dd53e2b487da03fd02396306d248cda0e99f33420f577ee8ce54b67080a80d1ec69821bcb6a8839396f9652b6ff72a70

d131dd02c5e6eec4693d9a0698aff95c2fcab50712467eab4004583eb8fb7f8955ad340609f4b30283e4888325f1415a085125e8f7cdc99fd91dbd7280373c5bd8823e3156348f5bae6dacd436c919c6dd53e23487da03fd02396306d248cda0e99f33420f577ee8ce54b67080280d1ec69821bcb6a8839396f965ab6ff72a70
                                      ^                                                                                ^                                                                               ^

have the same MD5 hash. Although testing this hypothesis with this MD5 generator, they do not have the same hash.
The first string hashes to edde4181249fea68547c2fd0edd2e22f and meanwhile the second to e234dbc6aa0932d9dd5facd53ba0372a which is not the same.
Why is it being said that these two strings produce the same MD5 hash value?

... in which it clearly states that these two strings ...

No. It clearly states "...  two different sequences of 128 bytes ...".
There is a huge difference in these statements. In the first the strings are taken as they are. In the second one will hopefully realize that these are 256 character long strings which consist of hexadecimal characters and that one needs to convert these to binary to get the 128 bytes.
Once this conversion is done and the MD5 is computed from the actual 128 bytes one will see that both byte sequences result in the same MD5, namely 79054025255fb1a26e4bc422aef54eb4 (matching the article).
This can for example be reproduced by using this site and choosing bytes in format hexadecimal as input.


Is it okay to add self-signed certificate on trusted store in this situation? AFAIK, using self-signed certificates on public usage has following problems.

Cannot verify its authenticity on the first-time key exchange. However, if first key exchange was successful, following communication would be secured by comparing stored server cert. on clients.
If cert.'s private key is stolen, cannot revoke that cert.

If they are all the risks of self-singed cert, in the following situation, I think it is not that bad to use self-signed cert.

All the clients are managed. So if the cert's private key was spoiled, I can remove all the previous certs on all clients and re-new it for new self-signed cert manually.
I can pre-install self-signed cert to clients by offline before its first communication to server. So there's no risk of accepting fake cert on first handshake.

In this circumstance, is it okay to use self-signed certificate? or there still have important reason to use CA-signed certificate?

If I correctly understand, you want to build a correct SSL connection without having to buy a certificate to a third party well known provider.

As you said that you could know all clients and pre-install certificates before first communication to server, it is perfectly fine. Simply if you directly use self signed certificate you could lead browsers (and users) in various corner cases, that you could easily avoid.

My advice would be to build a mini CA (openssl comes with all you need for that, include tutorials):

you create a self signed cerficate that will be used to signed auxilliary certificates and store the private key in a secure place
you pass it offline to you clients, and ask them to install it as a root certificate (all root certificates are by definition self signed)
you create a server certificate that you sign with the self-signed certificate and use it normally.

That way all browsers will process smoothly a standard certificate chain. As a bonus, you could even publish an initialy empty Certificate Revocation List, that you could later use if you needed to revoke one certificate.


Dynamic tools to detect vulnerabilities in software applications written in c? I am doing a project on detecting vulnerabilities in Windows 7/8 for software applications. Some of which some have source code available and some do not.

Please suggest some technique that can help me detect vulnerabilities either at compile time or run-time.

Is there any new way that can be used in finding out the buffer overflow vulnerability?

Avalanche is a dynamic defect detection tool that generates "inputs of death" - input data reproducing critical bugs and vulnerabilities in the analysed program.
BoundsChecker is a memory checking and API call validation tool used for C++ software development with Microsoft Visual C++.
Valgrind is an instrumentation framework for building dynamic analysis tools. There are Valgrind tools that can automatically detect many memory management and threading bugs, and profile your programs in detail.
!exploitable (pronounced “bang exploitable”) is a Windows debugging extension (Windbg) that provides automated crash analysis and security risk assessment. The tool first creates hashes to determine the uniqueness of a crash and then assigns an exploitability rating to the crash: Exploitable, Probably Exploitable, Probably Not Exploitable, or Unknown.


How can CPU designers prevent information leaks from speculated execution? We know about short-term measures to mitigate the Meltdown and Spectre vulnerabilities in certain microprocessors where speculative execution has measurable effects on cache timings (mainly patches to microcode, operating systems and any applications containing trust boundaries).

What are the long-term solutions to the problem?

Obvious, simple solutions such as "don't speculate" or "ignore cache when speculating" are unlikely to be acceptable due to the performance considerations that introduced speculation in the first place.

Perhaps speculated instructions could use a separate cache, which is only copied to main cache if the speculation succeeds?  If not, why not?

Could processors add privilege information to page table entries, to make Kernel Page Table Isolation automatic (and reduce its performance impact)?

Are there other design changes that improve security without a big performance hit?

Fixing Meltdown is simple: if the CPU is performing speculative execution, don't read data from protected areas of memory.  The fact that Meltdown is almost exclusively Intel-only shows that it's a design flaw, rather than an inherent side effect of speculative execution.

Fixing Spectre in the general case is much harder.  Spectre is about inducing a program to speculatively malfunction, then observing side effects of that malfunction.  You cannot get rid of all the side effects: even if you could roll back all the caches, buffers, tables, and whatnot, there's the simple fact that speculative execution involves speculative execution.  Running speculative instructions takes a (somewhat data-controllable) amount of time, which can't be undone short of figuring out time travel.

What can be done is to greatly increase the difficulty of inducing a speculative malfunction.  Currently, most CPUs have no concept of "process", and use only part of the address when performing lookups in the branch prediction table.  If branch prediction data is tagged to indicate which process it belongs to, or if the branch prediction table is flushed on each context switch, the ability of one program to mis-train the branch predictor's actions for another program are effectively eliminated.  Similarly, if branch prediction is performed using the full address, a program can't attack itself (for example, Javascript wouldn't be able to use Spectre break out of a web browser's sandbox).


Can running a script while logged in compromise my facebook password? In websites related to facebook malware analysis and information, we often see messages to the effect of if you have run this facebook app then your account has been compromised, or if you went to your browser console and run this script then your account has been compromised. Change your password immediately.

I can understand running a script while logging in may make it possible for messages to be sent or posted on walls automatically, but how is it possible for someone to obtain my password by me running a script or a facebook application? Does the password information that I sent to authenticate myself when I opened facebook somehow stay around in the browser until I log off? I can imagine cookies or some other temporary internet files storing my login session information somewhere that the browser can access, but wouldn't such information just give an attacker control over the current session? How would someone get hold of my password that I only enter during the login screen to authenticate myself in, by simply me running a script?

Short Answer: No, it can't.

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

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


How to implement reset password for a password manager How could I best implement a reset password functionality for a password manager? I'm currently saving a hashed + salted master password, which is hashed with PBKDF2, and encrypting the passwords with the master password itself, however if a user has lost his master password this means the passwords can't be decrypted.

I thought about saving a version of the passwords encrypted with the master password and a version encrypted with the users email + some random token generated when the user creates his account, but would this be safe? Is there any best practice when doing this?

The user's email also only gets stored as a hash.

So to clarify my question, are there any best practices for recovering data encrypted with a password if that password is lost?

EDIT

My current idea is generating a second key to encrypt all passwords, and encrypting this key in an image through steganography the user can store on an usb, but then all passwords would be saved twice in the database (encrypted both times), so I don't know if that's a risk or not.

EDIT 2

Final version, with the help of @A.Hersean 's answer.

I'm going to generate a key with which all passwords are encrypted, and this key itself can be encrypted with a password and backup password (which is saved inside an image) and those two encryptions of the key will then be saved to the database.

To answer your question "So to clarify my question, are there any best practices for recovering data encrypted with a password if that password is lost?", the best practice is you don't recover encrypted data when you loose your password. Because the point of encryption is to not be able to decrypt without the password, being able to do otherwise will weaken your encryption scheme. So you must ensure not to loose the password in the first place, for example by writing it down and placing it into a safe.

For your question "a version encrypted with the users email + some random token generated when the user creates his account, but would this be safe?", the answer is no, that wouldn't be safe. Because you will have to save the token (and the email address or its hash), it's the same as saving the password in clear text.

If you need flexibility, don't encrypt data with a password. Encrypt your data with a randomly generated encryption key, then encrypt this key with a password and save the key in its encrypted form. You can then encrypt the key with other passwords and save it too, maybe elsewhere (in a vault). Keep in mind that the resulting strength of the encryption will be the one of the weakest password used.


Is it possible become root through a broken symlink owned by root and globally writeable? I'm looking for a vulnerability on a server.  I'm looking in the /var directory and I get something like this:

drwxr-xr-x  3 root root 4.0K Aug 14 21:02 kerberos
drwxr-xr-x 12 root root 4.0K Nov 11 05:04 lib
drwxr-xr-x  2 root root 4.0K Jun 10  2014 local

lrwxrwxrwx  1 root root   11 Aug 14 21:00 lock -> ../run/lock     <-- CHECK THIS

drwxr-xr-x  3 root root 4.0K Aug 14 21:05 log
lrwxrwxrwx  1 root root   10 Aug 14 21:00 mail -> spool/mail
drwxr-xr-x  2 root root 4.0K Jun 10  2014 nis
drwxr-xr-x  2 root root 4.0K Jun 10  2014 opt
drwxr-xr-x  2 root root 4.0K Jun 10  2014 preserve
lrwxrwxrwx  1 root root    6 Aug 14 21:00 run -> ../run
drwxr-xr-x  4 root root 4.0K Aug 14 21:00 spool

If I look at the permissions of the lock "file" I see that the permissions for others is rwx. I suppose it is therefore possible for another user who is not the owner (root in this case), to read, execute and write this "file", so I check what kind of file lock is:

file lock
lock: broken symbolic link to `../run/lock'

stat lock

File: ‘lock’ -> ‘../run/lock’
  Size: 11          Blocks: 0          IO Block: 4096   symbolic link
Device: fb01h/64257d    Inode: 6424574     Links: 1
Access: (0777/lrwxrwxrwx)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2015-11-14 00:18:52.218518690 +0000
Modify: 2015-08-14 21:00:52.000000000 +0000
Change: 2015-11-11 04:56:35.543404826 +0000
 Birth: -

According to this information, is it possible to get root, use this permission to access other information or execute commands?

For instance I tried:

echo  "ls /etc" >> lock

But I get Permission denied.

Some questions:

Is my interpretation about the lock permissions correct?
Can I do something to get an advantage with this broken symlink?
What kind of questions must be ask with this broken symlink?

The permissions on a symbolic link are mostly meaningless.  If you don't have read permission, you can't see where it points, and if you don't have write permission, you can't retarget it, but that's all -- and actually creating a link with permissions other than 0777 is quite the trick.  The permissions on the target of the link determine what you can do with the target: if you were to replace the target of a root-owned broken link with a file you created, the target would be owned by you, and would act appropriately regardless of whether you accessed it directly or through the link.


Difference between root login and passwordless sudo Cloud images of some popular operating systems do not let the user to log in as root, yet they use a very standard user name (for example ec2-user, ubuntu) and allow these users to use passwordless sudo.

What is the reason for this choice?  Is it more secure than running as root?

Is it hoping that automated attacks will not try these obvious usernames? Is it somehow requiring different permissions to be present at the ssh server? Is this just a piece of marketing to remind me whose services am I using?

Or is it just trying to make me not use root account (hoping I do not use sudo su all the time)?

I am assuming that only ssh keys are used to log in; no passwords.

Honestly, this is probably largely an attempt to protect the user against themselves.  One of the biggest benefits of "don't run as root" is that mistakes don't (usually) destroy the whole system.  (On desktops, this is of limited value -- I'd rather destroy my Apache configuration than all the data in my home directory!)  If you are using ec2-user, you at least need to realize you're escalating privileges by using sudo.  In that way, it is similar to UAC on Windows for an Administrative account.


At what level of abstraction should a developer work with with regards to cryptography? I have recently came across an old blog post by Jeff Atwood which got me thinking.

  What could be easier than a EncryptStringForBrowser() method which has security and tamper-resistance built in, that's part of a proven, domain-expert-tested set of code that thousands if not millions of developers already rely on?

Obviously the first rule of cryptography is to never roll your own. However, how far should a developer take this?

Should they build upon the cryptography libraries present in the programming language? Should they use third party cryptography libraries? Or should they take things on step further and use a library that takes care of everything, such as uLogin for PHP for example.

If a third party library is to be used, how can a non-cryptographer verify the security of said library besides going by it's reputation.

Half of cryptography is about the raw algorithms, like SHA-256 or AES. The other half is about assembling these algorithms into complete protocols like, for instance, SSL/TLS; designing a secure protocol is not easier than building a secure algorithm. When a developer meddles with an algorithm, then, by definition, he is in the process of creating his own protocol, i.e. doing his own crypto. Thus, caution is advised.

In an ideal world, a developer would:

analyze the problem he is trying to solve;
find an existing, vetted, thoroughly verified protocol which matches his problem;
use a library with a well-designed API, which implements the protocol (and its underlying cryptographic algorithms) with all the care that is needed for such things.

Unfortunately, the real world happens to be, as it were, real, i.e. not ideal at all. Available libraries often have a difficult to use API, mostly because the library designer was overenthusiastic: he took great pains to understand how the protocol works, and he wants to share. Thus, he makes an API which exposes a lot of how the protocol works internally, and the library user is confused.

Moreover, there are not so many ready-to-use protocols. You would like to find a protocol which applies to your problem; but you often have to squeeze and shove and torture your problem until it looks like something which fits one of the few existing "all-purpose" protocols (namely, SSL or bcrypt). When your only tool is a hammer, all problems are strongly expected to behave like nails.

And, of course, developers do not analyze their problems. They first code it, then they throw cryptography at it as a kind of exorcism against the demons of insecurity.

Developers should not have to think about cryptography except at a very high level of abstraction, using existing implementations of protocols. But since it is not practical, due to the general lack of ready protocols and available implementations, developers must get their hands dirty and understand cryptography down to the minutest details. This is not specific to the field of cryptography, but cryptography has an aggravating characteristic which is that you cannot test security: you can know that your product is secure only by having many people look at it and think real hard. If you are outside of the existing protocols where such scrutiny already took place, then you are doomed to do your own thinking.

Now if you think that my conclusion is that, on average, cryptography is sloppily applied by developers who do not grasp it, leading to countless vulnerabilities and a general state of rampant chaos, well, you guessed well.


Does the saying "physical access = game over" apply to smartphones, too? I was surprised to read in the responses to this popular question that it's considered nigh impossible to secure a computer system if intruders have physical access.

Does this apply to smartphones as well? Let's suppose I have done the most I can to secure my phone on a software level (e.g. encrypted storage, restricted app permissions ... whatever you consider "maximally secure"). Is physical access still game over?

This seems like an important issue, as there are many situations in most people's daily lives where they leave their cell phone on their desk as they take a break or what have you.

Technical answers are welcome, but I would personally appreciate responses that are legible to someone without a background in information security.

This question is related, but it deals more with surveillance technologies that might be built into a smartphone, not the options available to a malicious individual with physical access.

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

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

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

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

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

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


Does it matter that my browser shows an out-of-date certificate when a website uses service workers? A website I frequent (a Discourse forum) uses Let's Encrypt TLS certificates which are updated every two months with a valid period of three months. But the certificate information shown by Chrome says that the certificate is out-of-date and invalid. Oddly, when you click the padlock icon it does still say "Certificate (Valid)", it's only when you click on that menu item to see the certificate details that it says it's invalid. I believe this is because Discourse installs a service worker, so that loading the page doesn't actually sent an initial network request (though it does then send a request for the live data from the forum.) Here's a video with it both showing that the site is correctly secured, while the certificate is expired.
https://www.youtube.com/watch?v=vtRydggAHsI
Are there any security risks with service workers and short term TLS certificates? I assume that any subsequent requests the page makes would use the current certificate. Is this really just a Chrome bug that it shows the outdated certificate?

If the system's time and/or date of the device you are using to browse the website is miss-configured, you can see a valid certificate shown as invalid. This can happen in two possible scenarios:

The system's date is before the "Not valid before" value of the
public certificate.

The system's date is after the "Not valid after" value of the public
certificate.


Why would image resources loaded from different origins triggering HTTP authentication dialogs be harmful? From https://developer.mozilla.org/en-US/docs/Web/HTTP/Authentication, it says:

  A potential security hole that has recently been fixed by browsers is
  authentication of cross-site images. From Firefox 59 onwards, image
  resources loaded from different origins to the current document are no
  longer able to trigger HTTP authentication dialogs (bug 1423146),
  preventing user credentials being stolen if attackers were able to
  embed an arbitrary image into a third-party page.

How could user credentials be stolen? The authentication happens between the user and the image source website, while the "third-party page" website is not involved.

As outlined in the bug report, the issue is that an authentication dialog shows up on trustworthy.com, so oblivious users (and let's be honest, many users who pay attention as well) will type in their username and password, not realizing they're actually sending it to malicious.com. Combine this with a very similar looking domain (e.g. trustw0rthy.com), and the only reason a user wouldn't give away their credentials is because they've never seen trustworthy.com use Basic Auth before and it made them suspicious.

As an example:

Let's say your online banking at bank.com requires you to log in via Basic Auth. Now the attack would work like this:

An attacker manages to embed his image, served from malicious.com,  somewhere in bank.com where the user (you) will load the image.
You load the page on bank.com that embeds the attacker's image, and the browser pops up a Basic Auth dialog.
You type in your username and password for bank.com, believing the site is asking you to log in, but the browser will send them to malicious.com instead.


Are there any Benefits of Ajax Fingerprinting? I was reading an article on "Web 2.0 Defense with Ajax Fingerprinting and Filtering". The paper emphasis on using Ajax Time stamp header to identify Ajax calls.

// Building request
    http.open("GET", "/ajax-only/headline", true);
    http.setRequestHeader("Ajax-Timestamp",Date())

With the following header attached to the request

Ajax-Timestamp: Tue Oct 24 2006 17:37:46 GMT+0530 (India Standard Time)

I am confused what are the security benefits of identifying Ajax calls from normal requests.

I've read this article a while ago (I think it's about 7 years old), and with all respect to Shreeraj Shah (the author) I completely disagree, and I extend my disagreement to most of his "security" methodology. Security by obscurity isn't the answer!

Here's something taken from the original (IN)SECURE article (page 25) explaining the benefit of this technique

  This fingerprinting technique helps in determining the type of client
  code that has sent this request. It is possible to lockdown resources
  for just the right client on the server-side as well. This type of
  header is harder to add by automated crawlers and bots since the logic
  and calls need to be understood first. Consequently, automated attacks
  on your Ajax resources can be avoided.

Mr. Shah is assuming that his method adds security because he's leveraging the attacker's ignorance of his request method.

My personal opinion is to treat this as false information, or outdated information at best.

Update:

Now that I think about it a bit more, I think I haven't targeted your exact question

  Are there any Benefits of Ajax Fingerprinting?

I don't see any security benefits for that at all. There might be some benefits regarding the usage of the application. One example would be a URL like this

example.com/article/124

You might wanna view the article when the page is visited normally and provide the information in JSON or XML if the same URL was requested with Ajax.


Separate server between web server and database server Possibly basic question from a developer, not a security expert.

AFAIK, a very common setup for web sites is to have 1 or more web servers behind a firewall and load balancer, with the web servers sending requests to a database server via an internal network (not accessible from the outside world).

I have now been told by a security consultant that this is not secure, because if a  hacker gains access to a web server, they could then somehow send requests to the database server.

They recommend having an additional server between the web servers and the database server, where the web servers send requests to the additional server, which are then passed on to the database server. The database server would only take requests from the additional server, not from the web servers.

I'm a bit confused why this additional server is needed to make the system secure. Seeing that the web servers need to access the database to serve HTTP requests, how does having the additional server make a difference?

This sounds a bit like "Turtles all the way down". I think it depends on how you tier your application and webservers and how your application is designed. In most environments I've seen there are multiple tiers (which are segregated by eachother):

Loadbalancer
Web tier (generally manages SSL/TLS and static content as well as caching)
Application tier (this runs your dynamic content)
Database tier (generally sits in an isolated database segment)

This is a common architecture. My assumption is that he's thinking if your web-tier (closest to the internet) is compromised that you wouldn't be able to directly compromise the database as there is an app-tier in between.

The reason some consultants assume this is correct is because there might be different technologies used. For instance your web server maybe running on Apache Webserver but your app-tier may be on SpringBoot.

It is a similar story where people tell you to get two brands of firewalls after eachother, just in case one gets compromised.

Is it a good pattern? It is. is it fool proof? Probably not. I think it's something you can consider, but review whether it makes sense financially to add these tiers versus the risk you are running. Depending on the nature of the data and the cost involved re-engineering you may choose not to follow his advice.


Implications of having a service account in AD use RC4 rather than AES for Kerberos? Bear with me, I know this is sloppy, but here is the back story:

We have a partner that uses Jira and is using spnego with a custom auth back-end that expects certain group membership in the token. Assuming the presented token meets the requirements, the user is granted SSO access to Jira.

We have a two way non-transitive external trust from one of our child domains with this partner. Since this is an old and crusty external trust and not a selective forest trust, AD does not maintain the information necessary for Kerberos to work for anything other than interactive logons between the domains.

There is an SPN registered on their side for this service, but clients on my side cannot locate this SPN, because a Kerberos referral is not possible. This is, obviously, a problem since it causes the clients to fall back to NTLM and they don't SSO.

The proposed workaround is to make a service account on our end as well and register a SPN on our side for the same service identical to theirs. The passwords will have to be identical on each side. This will negate the need for a referral to find the appropriate SPN since we're effectively mirroring it on our side and "tricking" the clients in our child into using it rather than the proper one on their side. They are also proposing that we lower the encryption algorithm for these mirrored accounts to RC4 rather than AES.

This is where my knowledge starts to falter, I don't know why the step of lowering the encryption algorithm to RC4 is necessary. I also don't know what the security implications of it may be.

What are the implications and why can't we just stick with AES to make this work?

The biggest reason I can think of as to why they might want to use RC4 is because of compatibility with Jira (and or this custom auth backend that we cannot vet.)

AES128 support was introduced along with Server 2008 and Vista, and AES256 with 2008 R2 and Win7.  However, the KDC will automatically negotiate down to (for instance) RC4 when talking to, say, a Windows 2000 client, during pre-authentication. So there should be no need to force it.

Of course, you can also configure user and computer accounts to support or not support DES, AES128, AES256, etc.

The implications are simply that it's not as strong of an encryption type as the newer AES ones. But it's not awful either.

I  would certainly be interested in hearing their reasoning for why they want to use RC4. The trick that you're proposing with mirrored SPNs is a whole other can of worms, but the encryption type used between clients and KDCs should have essentially nothing to do with whether it'll work.


What does Zerodium do with their bought exploits and bugs? I came across the cybersecurity company Zerodium. They offer bigger bounties than most of the companies calling for bug hunters:

Because of the bigger bug bounties, bug hunters sell their found exploits/bugs to Zerodium rather than to the company having the exploits/bugs.

On their "About us" page they don't mention what they do with their bought exploits and bugs or how they earn their money. In their faq they mention:

  ZERODIUM customers are mainly government organizations in need of specific and tailored cybersecurity capabilities, as well as major corporations from defense, technology, and financial sectors, in need of protective solutions to defend against zero-day attacks. Access to ZERODIUM solutions and capabilities is highly restricted and is only available to a very limited number of organizations.

Is there any further information to their customers and what Zerodium does with their purchased exploits and bugs?

Zerodium is not "well-known for their big bounties", but they are well-known for aggressive marketing. They are actually fairly small players in the whole exploit broker market, and they pay up far less than they advertise. In general, companies like these will buy weaponized exploits and resell them, usually to governments which use them to, among other things, exploit and track dissidents or even journalists.

Note that the price they list is the maximum payout. The vast majority of exploits will be bought for a far lower price. It is more likely to align with the price they sell it for, as they need to make a profit as ethically-challenged opportunists. As governments have ample money from tax payers, they can afford to pay non-competitive prices and ensure that Zerodium and their ilk sell preferentially to them.

The 0day industry is composed of a number of different companies, some of which are explicitly government contractors, as well as private individuals who buy and sell exploits. Generally, you give them a weaponized exploit and they pay you slowly over a period of time. If for whatever reason the exploit is patched before they have finished paying out, they will stop paying you. This provides an incentive not to use up and burn the exploit on your own. Exploit brokers often know each other and word about which vulnerabilities are in possession travel fast, which itself makes it difficult to try to sell the same vulnerability to multiple different companies. This is true of most exploit brokers.


Protecting a private key by spreading it over multiple places Is it safe to split a private key file and put it in different locations?
I mean can somebody actually do anything with only a part of a key?

Just splitting the file up will not have the desired effect (as A.Hersean explains in their answer).

I think what you're looking for is "Secret Sharing" algorithms, most notably Shamir's Secret Sharing algorithm (thanks @heinrich5991), where the secret is split up into N pieces and given to different people for safe-keeping. To reconstruct the secret, all N pieces (or in some variants, only k of the pieces) need to be brought together. The attacker gains no information unless they have all the pieces.

Although used in many applications, I don't believe it is available in openssl or CAPI. There are many robust open source implementations -- see this question, but you'll need to do some homework to decide if you trust the implementation to not be back-doored.

There is also the related concept of "Multi-party encryption"; where you  encrypt the secret with multiple people's public keys, and then all of them need to participate in decrypting it. Here's a SO tread about it:

Encryption and decryption involving 3 parties

You can do a poor-man's version of this using only the RSA implementation you already have by chaining RSA encryption:

RSA(key1, RSA(key2, RSA(key3, secret) ) )

If you want 3 people to encrypt, but only 2 of them need to be present to decrypt, then you can store 3 versions of the ciphertext:

RSA(key1, RSA(key2, secret) )
RSA(key2, RSA(key3, secret) )
RSA(key1, RSA(key3, secret) )


User "ASP" logged in to windows server - hacking attempt? I run a windows server 2008 which I connect to both via VNC and via remote desktop. Yesterday I noted when I connected to it via VNC that another user was logged in. See images.

Notes:

I have no idea what ASP is. It seems to be a guest account when I looked it up in accounts as Administrator.
I have no idea what "SCOOTER-PC" is.
I tried my usual passwords to log in as the ASP-user, but these were incorrect.
I have not seen this before, and as I just recently started using remote desktop I figure it might be that that session somehow is still being active.

Your server seems compromised!

the steps you should take is to immidiatly make a IP scope for the remote desktop and VNC application in windows firewall so only the IPaddress of the remote (or LAN if its in the same network) should be able to acces this!

Also, the user ASP should be deleted at once, be sure to run antivirusses like Malwarebytes and install updates to make sure there isnt a keylogger, and change the passwords for the Admin (and all other users if there are any).

good luck!


How to retrieve type of device starting from its public ip Given a public ip, is there a way to retrieve what's lying behind?

I mean if I use nmap -PO 159.149.xx.xxx I am able to know if the device is alive (responding to ping) and which ports are open.

But basically I don't know if it's a switch or a machine (computer running Windows) having a public ip.

Any help will be highly appreciated.
Thanks

Apart from nmap, try to telnet the ports yourself. Some servers provide headers, like SSH does (this is how nmap identifies the ports):

root@debian:~# telnet 193.231.X.Y 22
Trying 193.231.X.Y...
Connected to 193.231.X.Y.
Escape character is '^]'.
SSH-2.0-OpenSSH_5.5p1 Debian-6+squeeze5
^]
telnet> cl
Connection closed.
root@debian:~#

You can see the SSH being run on a Debian server above.

Web servers usually react to couple of CL+LF, but ifnot, you can issue a GET request:

root@debian:~# telnet localhost 80
Trying ::1...
Connected to localhost.
Escape character is '^]'.

GET / HTTP/1.0

HTTP/1.1 200 OK
Date: Tue, 10 Feb 2015 11:44:04 GMT
Server: Apache/2.2.16 (Debian)
Last-Modified: Thu, 30 Oct 2014 20:09:38 GMT
ETag: "c357-b1-506a975bb4480"
Accept-Ranges: bytes
Content-Length: 177
Connection: close
Content-Type: text/html

It works!

This is the default web page for this server.

The web server software is running but no content has been added, yet.

Connection closed by foreign host.
root@debian:~#

Same Debian here. You can see the space before the GET request, I've tried couple of new lines.

Remember, this applies to services that do not default to their usual port (like SSH on some ABCD port, or a web server on ABCD port. Also these are examples for known services, you might however bump into headers of some other service. So first use nmap to find open ports, then check them manually if nmap doesn't know them - some wording might represent an useful piece of information for a human than for nmap.

One more thing: use more flags and extend the search on all ports, using various nmap options, i.e. (careful if you're crossing third party networks as they might not like your port scanning):

nmap -p1-65535 -sV --version-all -sU -sN --reason -T5  193.231.X.Y

And, if you have access on some host on the same LAN/VLAN, look in the ARP Cache table and check the MAC OUI (first three bytes of the mac address), then look it up on the net, getting the vendor name (Wireshark provides an OUI Lookup Tool). Usualy some PC/Server NIC is not manufactured in the same plant asa a switch (there are exceptions, take HP for example, but not Cisco or Juniper, they don't manufacture PCs or Servers).


What is the best way to transmit password hash over unreliable TLS? I have TLS connection between my server and client. I have no certificate, so the connection is susceptible to the Man-in-the-middle attack.

I fear that attacker could intercept the password hash and use it to authenticate himself in my application.

What is the best way to transmit password hash? To use server nonce or client nonce? And what hashing algorithm should I use?

You can't.

There is no secure way to transmit it if you can't authenticate the server and establish a secure channel. If you can't authenticate the server then you can't be sure if you are talking to the server or the attacker. Hence, even if you use TLS to establish a secure channel, it doesn't protect you at all since you could be talking to the attacker while thinking that you are talking to the server.

The certificate is essential. Without it, or some knowledge of the public key of the server, you cannot be sure that you are really communicating to the server as an attacker could act as a man in the middle between you and the server.

TLS use Diffie-Hellman for the key exchange. If you look at the security section of the wikipedia page you will find the following attack which is exactly what you are vulnerable to.

  In the original description, the Diffie–Hellman exchange by itself
  does not provide authentication of the communicating parties and is
  thus vulnerable to a man-in-the-middle attack. Mallory may establish
  two distinct key exchanges, one with Alice and the other with Bob,
  effectively masquerading as Alice to Bob, and vice versa, allowing her
  to decrypt, then re-encrypt, the messages passed between them.

Conclusion

You need to have a valid certificate to be able to authenticate the server or you will be vulnerable to man in the middle attack. An easy way to achieve that is to include the server certificate in your application which is also known as certificate pinning.


public key distribution from a central server I'm trying to code up a encrypted communication program. Originally I was thinking that I would use public key cryptography and then I would keep the public keys in a database where users could query the database for another user's public key to encrypt their message. However this allows me to read their message if I ever sent them my public key instead of the their intended recipient's public key.

Is it possible to have forward secrecy if they grab the public key from the central server, which I control? It seems to me that if you use some forward secrecy algorithms like STS I would still be able to send both users my public key and they would be none the wiser.

It's not possible to exchange public keys over an untrusted channel without the help of a trusted third-party. Even STS assumes that either: a) the public keys were exchanged in advance; or b) certificates are used to help establish key trust (so either a CA, Web of Trust or similar is needed). In your scenario, you're acting as the trusted third-party, asserting to each user that a given key belongs to him/her, and that you're not secretly performing a man-in-the-middle attack (sometimes called institutional MitM). In other words, you're correct in your assumptions.

I'd suggest looking at this answer for some insights on the subject of public key trust. I'm afraid there's little I can suggest you in order to improve over the existing models though...


How do large organisations manage access for their Instagram account? A platform like Facebook has fairly standard access management for Facebook pages - where multiple individual user accounts can be assigned to roles with varying privileges on the Facebook page, and the person(s) with the admin role can revoke those privileges.

Instagram on the otherhand, has a strict one username/one password access model.

Where content management can be abstracted using a tool like Buffer or Hootsuite (which allows content to be scheduled and queued via a desktop browser application), in order for someone to actually post to Instagram they need to use their phone, with the single username and password, to post the content.

This seems sketchy - a large organisation that is perhaps providing customer service via their instagram account, would need multiple people having access, and there's what to do when someone gets sick etc.

But if they all share the password - it seems a recipe for being locked out of your account, an employee going rogue etc.

Is there any literature around how large companies are dealing with this currently?

It seems that Instagram just doesn't lend itself to use by an organisation - and I'm wondering how organisations deal with this.

Not a complete solution, but paid LastPass accounts (Premium, Family, Teams, or Enterprise) allow a group of individuals to share access to one or more groups of login objects.  The text of the password does not need to be visible as the LastPass Extension handles the actual login.

The down side is that once logged into a site, a rogue user can modify anything that does not require the original password to change.  For example, rogue user could change the contact e-mail address, then request a "password recovery".

On the bright side, if you stop trusting someone before they go rogue, you can simply stop sharing the object(s) with them instead of changing passwords.  Not much, but it's something...

Edit:  As AndrolGenhald says in comments, changing the PW may still have value.


Why should I offer HTTP in addition to HTTPS? I am setting up a new webserver. In addition to TLS/HTTPS, I'm considering implementing Strict-Transport-Security and other HTTPS-enforcement mechanisms.

These all seem to be based on the assumption that I am serving http://www.example.com in addition to https://www.example.com. Why don't I just serve HTTPS only? That is, is there a security-based reason to serve HTTP -- for example, could someone spoof http://www.example.com if I don't set up HSTS?

For usability reasons you need to offer a redirect to HTTPS from all HTTP URL:s. Otherwise first time visitors who simply enter example.com/some/page into the URL bar of the browser will be greeted by a connection error.

Serving the redirect does not make you more vulnerable. Users who don't have your HSTS entry in their browsers will make a HTTP request anyway. Whether or not there is a real service or not on HTTP is irrelevant to a man in the middle.

So you need to run a HTTP server, but it doesn't need to respond with anything but the redirects.


Why Skype doesn't ask for password every time? Every time I launch Skype on my desktop it doesn't ask for my password. It asks for the password only when I run it for the very first time. Is it secure? For me it's better to type the password every time, so nobody can launch Skype without my permission.

You didn't specify, so I'm going to assume you're running Windows. The advice here applies to all operating systems, but the specific details vary somewhat.

Skype, like a huge number of other apps, sites, and services, uses long-lived login sessions that are stored in your user account. Unless an attacker is able to either sit down in front of a logged-in session on your computer, or get you to run malicious software either within your user account or as an Administrator, those sessions are safe. Another user on the same computer would not have access to your sessions (unless they are themselves an Administrator, and possibly not even then depending on how the sessions are stored and whether you are ever both logged in at once); if they launched Skype it would either ask them for a password (if they hadn't used it on that computer account before), or resume their own session.

If you're worried about somebody else gaining access to those accounts, the first line of defense is preventing physical access to your computer by people you don't trust. Physical security is mostly out of scope for Security.SE, so I'll just mention that, if the computer is somewhat portable and you're worried it (or its hard disk) might get stolen, look into using full-volume encryption (such as Windows' BitLocker feature) so the thief wouldn't be able to retrieve any data.

The next (and often most important) line of defense is your user account on the computer. Make sure it has a strong password, and change that password if you expect somebody you don't trust may have seen it. Don't do something silly like put it on a sticky note in your office or use a really obvious password hint (or any hint at all). Make sure the computer is set to lock your session after some minutes of inactivity - 10 or so is generally fine - and when resuming from sleep, and lock it yourself when you get up to leave the room any there's a chance somebody else might take the chance to use it (the shortcut to lock your session is WinKey+L, or you can use Start or Ctrl+Alt+Del and select Lock). If your machine has Bluetooth, you can also pair your phone to the computer and configure the machine to lock automatically when your phone goes out of range (which is when you get roughly 30 feet away).

If you share the computer (with people who you do not fully trust), then the most important thing to do is make sure that everybody else uses a different user account than you do (they could each have their own, or could all use a single guest account, or somewhere in between). Make sure none of the less-than-fully-trusted people have an Administrator-level account (indeed, give them as little privileges as possible). In a situation like this, make especially sure to always lock the computer (or log out of your session) when switching users. (Windows' "switch user" feature automatically locks your session.)


Can malicious sites use session data from iframes? Let's say I have logged in to my site Genuine Site. Malicious Site has an iframe embedding Genuine Site. Will the embedded iframe in the Malicious site have access to my login credentials from Genuine Site which I have logged in, in another tab?

The user has no knowledge of the iframe hidden in the Malicious Site. It is a hidden DOM.

Should this be possible, the Malicious Site can now programmatically issue requests with proper credentials as the iframe has access to the session data. How should I rectify this issue?

No. A malicious site cannot interact with its iframes which point to other domains. It can only issue GET and POST requests without reading the corresponding responses, like any other web page opened in the same browser. A feasible attack would instead be clickjacking.

This question is a possible duplicate of the question Javascript and same origin iframes.


Where do products like BlueCoat and ForcePoint get there URL categorizations from? I recently had an issue where I released software which made use of a new URL and several of my customer sites complained that the software wasn't working within their wifi network.  It turned out that their respective Firewall software products of choice (some were using BlueCoat, others ForcePoint, Barracude, etc) were all blocking my new URL because it was categorized as "New" or "Unknown" or "Untrusted" or something.

My question is - What is the authoritative source of these categorizations?  They all seem to agree on my new URL's category, so are these products all using the same central authority (Google?) for categorization?  Is there some authority or organization I could have reached out to to get my URL categorized correctly before releasing my software?

I don't want all of my customers to have to add firewall exceptions in cases like this.

As a former, long-time bluecoat customer, I can give you some insight.

Two main sources:

Threat intelligence sources - many ingest the same sets of data regarding what's a malicious source and what is not. As a result, you're going to see a lot of overlap between products.
Mass quantities of people - Bluecoat specifically has people whose sole job it is to review new sites and suggest categorizations, or to review suggested changes to those categorizations.

What your customers are doing - blocking "new" and "unclassified" sites is absolutely best practice. Given the rise of fast flux DNS, and domain generation algorithms, the number of legitimate new domains is an order of magnitude less than malicious or spammy ones.

I'd suggest simply setting your customers expectations and understanding the support models for these major vendors to ensure that your new sites can be opened up as soon as possible.


How can I close my browser pop-up Ads? (can't be blocked) How can I close my browser pop-up ads?

When I use my browser. There's ads everywhere, even in the google main page.

I can't seem to close ads how many time I click close.

When I tried to block the ads with not allowing pop-up, I found that the setting is blocked (greyed).

What should I do?

Edit: Strangely only one user that affected. When I used another user it doesn't likely to happen even on the same browser.

When I use my browser. There's ads everywhere, even in the google main page.

Your computer (or at least, your browser) is infected with Adware (which I consider to be a special type of Malware).

So, uninstall your browser. Reinstall.

If that doesn't help, maybe some of the more common tools of spy- and adware removal will help, but I'll be honest with you:

I work with computers in all my jobs, and when one system shows such symptoms, it gets flattened, set up anew, and data is very selectively after extensive anti-virus inspection copied over to the new system. Trying to "fix" such systems is never giving you certainty it's not still infected, and I can't (neither for emotional, nor contractional reasons) accept the chance to work on a system that is infected with software that has the purpose of exfiltrating my user data (to show me targeted ads, or worse).


What does this Bruce Schneier fact mean? I came across a website called Bruce Schneier Facts, a parody along the lines of Chuck Norris facts, and saw the following fact:

  Schneier knows if Reiser did it.

What does it mean?

Answered by @SteveSether in their comment.

  Almost certainly it's referring to Hans Reiser, an OSS software developer who murdered his wife in 2006. en.wikipedia.org/wiki/Hans_Reiser (He did it, and later lead police to where her body was buried).


Communicate between two sites both with SSL I now have two websites - site A and B, both with SSL-certificate, and they have exact same users. So when a user log into site A and click the link to site B, I want to make him auto log in to site B.

It will be easy if I just use regular POST and GET to pass the user id form site A to site B(more specifically I am using PHP POST and GET). But I wonder will it be done under protect of SSL automatically or I need to do something more complicate to ensure the security?

A user is "logged on" site A because server A considers the requests from that user to be "linked beyond reasonable doubt" with the user identity. There are several methods by which such a result can be obtained; but usually, some authentication protocol was played (user shows his password) and then some sort of link is maintained, so that for each subsequent request, the server knows that it is "from the same guy as previously".

There are several methods to maintain this link. Main ones are the following:

Each request from the user's browser is a GET or POST which includes as extra (hidden) parameter some authentication token. The token was created by the server when the authentication protocol was executed, and each page sent by the server contains it.
An authentication token was sent by the server to the client, to be sent back to the server with each request, as a cookie.
The server keeps track of the client through the SSL session (when the client reconnects to the server, both client and server agree to reuse the cryptographic elements from a previous handshake, because they both remember the corresponding keys).

The third method is specific to SSL; otherwise, the fact that you use HTTP or HTTPS is irrelevant (except that with plain HTTP, the result would not be secure, but that's another debate).

HTTP cookies are attached to a site name. So if authentication to site A works that way, then the browser will not send the cookie to site B, and the authentication will not be automatically transported from site A to site B.

The first method, though, may work. It "suffices" that authentication tokens created by site A be recognized by site B. But, of course, you don't want other people to be able to produce "valid tokens" out of the blue. So this entails either some form of communication between servers A and B (A telling to B: "hey, I just created this token which authenticates that user), or cryptography (tokens created by A must then contain the user's name and some form of signature or MAC from server A, verifiable by server B).


How to solve race condition in 2-factor authentication solutions like RSA Security tokens or Google Authenticator? One of the reasons we opt to use 2-factor authentication is to minimize the impact of keyloggers. The theory is that even if an attacker is able to observe the user type in the token numbers, they wouldn't be able to use this information, since the nature of one-time passwords prevent their reuse.
However, if an attacker is able to observe the keypresses in real time, there is always going to be a small period of time between when the digits from the token are typed in, and when the "Enter" button is pressed. An attack tool can be easily scripted to take advantage of this lag to authenticate on behalf of the attacker.

I know that yubikeys submit "Enter" as part of the string of characters they send, but how to solve this for RSA and Google Authenticator tokens? Is there a solution?

Not really, at that point you are dealing with a compromised client and pretty much all bets are off.  The best you can do is ensure the user is aware of the failure which will (hopefully) result in them asking questions or trying again.  When a user connects the old user should be booted.  This should make a legit user aware of the problem even if they don't understand it.

Also, if a client is so compromised, there is likely no need for a race condition, the attacker could simply use the compromised client that the user is legitimately using as the launch point for their nefarious deeds.  This wouldn't throw off any alarms since both the good and the bad are coming from the same client.


What unique device fingerprinting information can an iOS8 app collect? As an addition to this question:

What unique fingerprinting information can an iOS7 app collect?

What remaining device fingerprinting privacy/security vulnerabilities still exist as of iOS 8? Can 3rd-party apps still access a list of other running apps? How effective is it to test custom URL schemes to determine what other apps are installed?

For example, there is some indication that the Whisper app is bypassing Apple's latest protections: http://www.zdziarski.com/blog/?p=4056

The are numerous opportunities for fingerprinting/privacy leakage at all levels of abstraction.  A good survey can be found on this upcoming PETS paper (full disclosure:  I am one of the authors).

With regard to your specific question, I guess you are looking for something analogous to iHasApp?  There are a number of ways of bypassing Apple's restrictions on, say, private APIs, (see Section 4.3.2 of 1).  FWIW, on Android, this is trivially done through the PackageManager.


Connected to my server through VPN. Should I change my key? I am using an SSH key to connect to my server (I've got Pageant to authenticate my key) and I forgot that I had the VPN on so I connected to the server (SFTP) while I was on it. Should I change my server key or is it ok?

I didn't use any extra software, but the windows VPN option with L2TP.

You're probably fine. SSH key-based login is designed to work over untrusted networks, without exposing key data - a VPN, even one which you don't control, doesn't change this.

At no point in the sign-in process is the whole private key sent across the network - this would be a massive flaw in the system if it was the case, and would make SSH key login useless over the internet.

In order to steal your key, the VPN provider would need to:

Perform a successful MitM attack on your connection to the server (which would require access to your private key to be successful)

and

Either inject a command to your system to read your private key, or coerce you into sending it to a remote point once they have a successful MitM in place.

If you were using third party VPN software, there would be a risk of that reading the key directly from your machine, but no more than the risk of any other software you run doing so.


Is it reasonable to use a security proxy when integrating two web applications? Background: We're in the process of integrating two web applications. The other one, application A, is a publicly accessible Internet service, which is provided by a third party and which offers Web Service APIs we'll integrate with. The other one, application B, is an old(ish) legacy application hosted in a company intranet. At the moment, application B can't be accessed from the Internet. It is quite a large system, and it exposes many open APIs that are meant for system integrations strictly inside the intranet. We can't afford to expose these APIs to be accessible from the Internet (intentionally or by accident). We control application B, and can implement the new features and APIs related to the new integration however we please.

I've done some digging, trying to find out the most appropriate solution for these security challenges. Some sources suggest that a Web Service security proxy (or a security gateway as some call it) would provide additional security in a case like this. This proxy is apparently often hosted in a DMZ. The proxy would basically perform the security functions that are required, such as message encryption/decryption, performing authentication and message integrity checks, auditing etc. I gather that an approach like this is most reasonable when integrating existing applications where the communications of the applications are not secured at the moment, but the integration should be implemented without having to modify the applications themselves. However, I would guess that the main advantage of a proxy in our situation (when there are only 2 applications) would be to only expose the limited API in application B which is needed for the integration to the outside and hide everything else. Some side benefits might be that it offloads some work that would otherwise fall on application B (such as cryptography, message validation, detecting possible attacks etc.) and might provide some additional protection for DoS attacks. Are my interpretations here correct?

The real question is, what would be the most secure way to make the API created for the integration accessible from the outside and prevent access to everything else in application B? Would a security proxy be a reasonable addition to improve the security of application B (in the ways I described or in some other ways), or is a direct point-to-point integration enough? What other approaches could be reasonable? The security aspects here are paramount, but I would naturally want to avoid over-engineering.

Let us assume that updating or replacing application B is not an option, that you're trying to retrofit security onto a legacy application.

In that case, my recommendation would be to use a WAF as "the most secure way to make the API created for the integration accessible from the outside and prevent access to everything else in application B?"

A Web Application Firewall is a mix of a proxy, as you've suggested, and a web app focused IDS/IPS.  Examples would be F5's Application Security Manager (ASM) and Imperva's SecureSphere.

At a minimum, a WAF will allow you control over the APIs that are accessed.  For example, if application B is RESTful, then the WAF can be used to prohibit access to this part of the API while also permitting access to that part of the API.  Depending on how the application is written, and the flexibility of the WAF, this can be true for multiple types of API (F5 iRules allow custom filters to be written in great power and detail).

In addition, a WAF will look for various attacks, things like parser attacks, overflows, command invocations, all the things you don't want someone sending to your legacy application server.


Generating multiple gpg private keys (for provenance) I’m learning about key management, encryption and GPG for provenance (verifying authorship). Using DevDungeon’s GPG Tutorial I learned that to export your GnuPG private key to your local computer, you use this command: $ gpg --export-secret-keys --armor XXX > ./my-priv-gpg-key.asc (where XXX is your unique hexadecimal identifier). Yesterday I used this command to generate the secret plain text secret key which I moved to cold storage. But today I invoked the same gpg command and entered the same passphrase which generated a new plain text secret key. I compared the two (yesterday’s key and today’s key) using the same  utility I use to view changes made to source code in git (p4merge). I noticed that the two gpg keys are slightly different. Roughly half is the same and the other half is brand new.

Now for my uber naive questions:

Is this a bad idea? If so, could someone clarify why this is a bad idea?
Should I only use the first one and delete the second one? Or is it perfectly alright for me to use either one going forward?  Which one should I use?

I Googled 'generating duplicate gpg private keys' and similar search terms but I had a hard time finding a discussion regarding my questions above. I also Googled ‘managing multiple private keys gnupg’ which turned up links to the official GnuPG manual on the topic of Key Management which was interesting but doesn’t answer my questions specifically.

It's version dependent.
First, a clarification. The output of almost any GPG command using --armor/-a is text form, that is the data is base64-encoded with header/trailer lines and a checksum added. In the past this was done to allow transmission over email which last century couldn't handle binary data; today it is rarely if ever needed for that purpose, but is still convenient for other things that can't handle binary, like cut&paste -- and HTML. (People sometimes try to post binary data on Stack and it never comes out usable, but posting 'armored' data, or similarly 'PEM' data used by OpenSSL and some other things, works right.)
It is not however plaintext, or not all. In cryptography, plaintext or cleartext specifically means not encrypted, and part of a PGP 'secret' key or subkey block is encrypted. The rest of it, containing the publickey value, userid, and affirming (aka 'certifying') signatures, is not encrypted, and is plaintext -- whether in binary or armored/text form.
In particular, the privatekey part of the OpenPGP (RFC4880) form of 'secret' key is encrypted using password-based encryption which, for reasons discussed in many other Qs you can search for, uses iterated hashing with random 'salt' which means if the same data is encrypted multiple times it produces different ciphertexts (with overwhelming probability).
Versions of GPG up to 2.0 use the OpenPGP form internally, in .gnupg/secring.gpg, so each time you export the same key it produces the same external form. GPG 2.2 changed to a new (gcrypt-based) file format in .gnupg/private-keys-v1.d/* so now when you export it must re-encrypt the data into the OpenPGP format, and because of salt as above the encrypted portion (ciphertext) is different each time. However the (plaintext) data it is encrypted from, and when used decrypts to, is the same.
Added: while checking something else, I discovered this is (now) in the manual:

--export-secret-keys ... GnuPG may ask you to enter the passphrase for the key. This is required, because the internal protection method of the secret key is different from the one specified by the OpenPGP protocol.

Also found a neardupe gpg: Every private key export (of the same key-pair) is different


How to use master password for GPG encryption after setting up Yubikey? I just setup my Yubikey 4 on Windows. How can I use master password for signing/encrypting when I don't have my key?

If the yubikey is not inserted I get an error "Please insert the card with serial number : XXXXXXXXXXX"

The "master password" is not a replacement for your private key -- it is simply a security measure to prevent someone from reading your private key from disk (before being written to the disk, the private key is encrypted itself using your passphrase).

In other words, now that your key is on the Yubikey, you must always use the yubikey in order to sign or decrypt anything.


Best practice for password distribution I am about to set up a new account on my Linux server for a user that lives in another state in the U.S.

I can't think of a good way to get them this user their password. There must be a standard mechanism for this, right?

Talk to them in a two way conversation in as close to real time as conveniently possible (in person/phone/instant message/email conservation) and give them an initial password that has to be reset on first login.

This is typically done with the chage command on linux/unix:

sudo chage -d 0 the_new_user

Verify afterwards that they got the new account using an independent method (e.g., if you called them previously; send them an email), so in case you were social engineered somehow (e.g., their cell phone was stolen or email was intercepted) there was an independent check afterward.  Also don't give them root or other elevated permissions until you've verified them.

EDIT: The initial password should be something random; e.g. 12 random characters generated by a computer.

EDIT2: Mitigating against eavesdroppers is simple if the people at both ends can be trusted.  If you can confidently identify the person on the other end of a phone/videoconference/etc give them a one time initial password (that they then have to reset), verify that they are in, and then elevate privileges.  If its a web app, this initial password could be an token in an emailed link (that works once; auto-expires after short period).  If its a work account, maybe only let the webapp send password emails from/to your local domain (which you've configured to use SSL).  Even if an eavesdropper intercepted, they would have to beat the person to initially using it (and then the legitimate user would have issues which would kick the eavesdropper off).

The thorny issue is one of establishing trust that a remote third party should have access to the account.   This starts with verifying the reason you giving this user this account?  Are they a well-known co-worker/acquaintance who needs access to something new?  Or did your boss say give you an email saying give joe@something.com access to server X?  Could you be social engineered (someone pretending to be boss over phone/stolen bosses email)?  This is not a straightforward task; however checking the instructions in person, or via video conference, or phone mitigates risks of the command being socially engineered.  Granted your boss may be social engineered -- maybe the new person should not be trusted.


Malware stole an executable file on my computer? Seems unlikely If you don't want to read all of the details, skip to the bottom; I'll make a summary.

I created a computer program as a proof of concept (I threw it together in 12 hours, so I wrote it in Visual Basic to get it done quickly). Normally I'd be using Linux but my client wanted a Windows version, so I resorted to VB.

Anyway, the program was designed for a computer rental company; if a computer is rented to a customer is lost, stolen or the customer stops paying, the computer can be remotely locked and tracked. I got the proof of concept working and installed it onto 4 computers running Windows XP. I showed those 4 computers to my client and demonstrated the software to them.

Once I'd finished the demonstration, I returned the computers back to my office and they've been turned off ever since. However, today (2 days after the demonstration) I noticed a computer check into my online service (e.g. my program was installed onto another computer). The model of the computer was completely different to the computers I was using and the serial number was reported as 'None'.

Also, I noticed the same computer check in 4 times within the space of 2 minutes from different locations in the world (according to IP address lookup). It's possible that it was 4 identical computers in different locations running the software at almost exactly the same time (The serial number was 'None' so I couldn't tell if they really were different computers or not).

I don't understand how this happened because I created the software on a Virtual Machine running a clean install of Windows XP with antivirus (the host machine was running Linux). The 4 demonstration machines were also clean installs with antivirus and they were fully updated. This means that during the 15 minutes those computers were connected to my clients' network, the program somehow got leaked. The computers never left my sight, nobody other than myself have ever accessed them.

How is that even possible and why would malware target a .exe file?

Summary

Created software on a clean install of Windows XP in a virtual machine (host was running linux)
Installed the software onto 4 computers and connected them to an unknown network for no more than 15 minutes
Nobody touched the computers besides myself
The software was then run from 4 different internet connections on what seems like the same computer two days after I unplugged the computers from the unknown network (the computers were never turned on again after being connected to that network).

Software is closed-source and was never given to anyone.

If it was malware, why did it steal an .exe?

The most important part of this post is "with antivirus".

Do you have automatic submissions turned on?  If so, those computers might have sent in an 'automatic submission' to the AV mothership at some point. It might have been flagged for evaluation, and possibly run in a controlled environment to see what behavior it would exhibit. These environments are often global, as sometimes malicious software does different things if run from a different subnet/country.

The other possibility (discussed by others) could be that it's random port scan or POST engine looking for vulnerabilities on the particular port you are using.  You should enter the IP addresses that are contacting you into an abuse list, and see if they are known scanners.

Mike


Is using VPN, Tor and ProxyChains together more secure? Similar question (Tor and VPN only).

All these three technologies seem to share the same goal, i.e. making internet traffic anonymous. Does it make any sense to try to use them together to increase security? Or, as BrunoMCBraga pointed out in a different thread (see link above), "a security chain is as secure as its weakest link"?

In theory yes, In practice maybe not but also yes at the same time.

If you were to use VPN and a tor network you remove one of the security layers in the tor network. tor uses relays and your path changes every time you use tor by using a VPN you would be using the same end point (assuming you went TOR -> VPN)

If you went VPN -> TOR, You would encrypt all of your traffic to your start point (The VPN Out interface) and then the TOR network would take over, the issue here comes with the VPN service its self, they could very easily see you are using the TOR network, this would be your weak spot you want to be under the radar with everything.

To make it secure you would need to buy an anonymous VPN and pay for it in bitcoins after rolling your bitcoins via a tumbler (depending how you obtain the bit coins will determine your weak spot in the chain, but the tumbler should fix most of that issue). To also secure the purchase make bitcoin transactions and VPN transaction VIA TOR.

then once you have the anonymous VPN you would not want to connect to your VPN from your home address (though anonymous VPNS hold no data so technically you shouldn't be able to be traced from your home address). then once connected to the VPN you can use the TOR network that way.

Personally I wouldn't use proxy chains it would become pointless seeing as you are using TOR also proxy chains leave behind clues on your machine (they like to leave behind messages about how they connected to the proxy chains). also it really makes the process slow for very little benefit.

To summarise:

Using a VPN creates an issue with its self as to obtain the VPN you would use personal information. though any extra security would be nice as you mentioned the chain is only as strong as its weakest link. The VPN would be the weakest link with personal information following you back (using a free VPN would end up in records being kept of your activities).

Keeping data private is not the issue here, its keeping the data disassociated from the owner. 01/01/1970 is someones birthdate, asking someones birthday can be a security question...sadly I dont know who this birthday belongs to, following?

Hopefully I kept mainly to the point in my answer.


Possibility of using CA as an attack point by governmental organizations under their pressure I was always concerned about the model of trust behind CA stuff we use . Well, for most of us, it is OK to trust them, since they are reliable organizations with  a bunch of solid experience.  Browsers trust hundreds of CA and their subCAs, and I don't know any CA center that is under international jurisdiction(if you know, let me too). I believe that there is 98,74621% chance of some subCA's private key leak, "sponsored" by government and embedded in some DPI systems and ready to use out-of-box.

You can just use MiTM attack once to decrypt needed comms. I don't think if there is anybody THAT paranoid to check 1000 times who is the issuer of SSL certificate.

And this would be a myth until I found this article here(it is in russian): http://blogerator.ru/page/snjatye-s-kanala-bezopasnost-fsb-https-soedinenij-sud-vzlom-facebook-proslushka-sorm

While there were other ways to obtain his password, I do belive (in some degree) in MiTM attack made by FSS RF.

So... are there any publicly reported cases of misuse of governmental power and trust of browsers' devs?
And what are the possible countermeasures?

The only thing that cames to my mind is to discard all CAs , so everytime you will see warning, or to write an extension for browser which will monitor this changes.

BTW, I think (not only)browsers should let us choose trusted CAs at the moment of installation,preferably based on physical and legal location of company and its servers.

Pre-Snowden, I would have dismissed this question as being in the "tinfoil hat" category.

Unfortunately, the NSA's pervasive misconduct (not to mention that of its "Five Eyes" junior partners, e.g. GCHQ, CSIS, and whatever the Australian and N.Z spook agencies are calling themselves these days), does indeed raise a troubling question.

The specific possibilities are numerous, but let's consider only two of them :

(1.) NSA could -- by asserting the USA PATRIOT Act and various other similar laws -- simply demand that a CA remit its root private encryption and signing keys. This would of course allow 100% effective masquerading by the NSA, with respect to any downstream certificate in the chain (since, the subordinate certs would appear to have been signed by the root CA's legitimate private key).

(2.) NSA could, also, install some kind of SSL interception (MiTM) box (which they are already well-known to possess) in front of the CA's root network architecture. This would allow some of the same functions as (1.) (but would be less flexible).

"Certificate pinning" can mitigate some of the risks here, but of course it would be of little use in the case of scenario (1.).

Unfortunately, what this really all goes to show is the truth of the familiar security aphorism, "if an attacker (in this case "No Such Agency") can get physical access to your box or network, it doesn't matter what security measures you may undertake; you'll be 'pwned' one way or another".

In the long run, I think the only halfway-valid mitigating step would be to only use Certificate Authorities that are :

(3.) Located outside the physical jurisdiction of the "Five Eyes" countries (as well as outside other countries whose political system cannot be trusted to respect privacy -- Russia, China, Iran, Germany, Israel, India, Pakistan, etc. spring to mind); and,

(4.) Are located in a country (or other setting) with a sufficiently sophisticated IT staffing environment so as to make them as immune as possible to subversion attempts on the part of state intelligence agencies working for the countries denominated in (3.) above; and

(5.) Are located in a network environment that is reasonably resistant to subversion on the part of the same intelligence agencies.

The problem here is, apart from the fact that the Venn diagram arising from the intersection of (3.) to (5.) above is likely to result in a very limited number of physical jurisdictions (Switzerland, maybe? I'd have said "Sweden", except for the Pirate Bay and Assange fiascoes), any CA located in this kind of setting would be a tempting target for "No Such Agency" and its partners in destroying trust on the Internet.

A CA is, by its very nature, a single point of failure in this respect, and it is only rational for a very well-resourced, unscrupulous entity like the NSA, to expend "whatever it takes" (keep in mind that the NSA's budget is already several multiples of the entire state budgets of many smaller nations), in order to be able to subvert all supposedly "secured" traffic that depends on the integrity of the CA's private keys.

So there you have it. Not particularly good news, but IMO that's an honest description of the situation as it now exists. Send all cards of thanks and appreciation to Michael Hayden, Keith Alexander, James Clapper, George Bush and Barack Obama (with their junior U.K. and other friends, along for the ride).


Does client side encryption really add security? A lot of password managers seems to promote client-side encryption as a key feature of their service. For example : LastPass, Firefox Sync, PasswordBox, etc...

They all say something like

  Even we don't know your master password and cannot decrypt your data,
  hence it is more secure.

Making the user think that it protects him against the password manager he is using.

But, in reality, they control the code that does the encryption on the client side and can change it whenever they want to instead do the encryption on the server and you would not notice anything.

So, does it add any security?

Client-side encryption does not protect against a malicious trusted application provider who decides to subvert their own system.

It does protect against attackers who breach the central store.  Those people cannot decrypt without keys, and if the provider doesn't have the keys (the key feature (sic) described above), then the attacker can't steal those in the same manner.  They'd have to compromise both the central store and the user endpoint(s), making a compromise of your data that much harder.

So does it really add security?  Yes.  Not for every use case, but for the use cases that realistically are a greater threat and a higher likelihood.


Why are we still using HTTP? I've been reading a lot of online articles and blogs about advantages of using HTTPS (HTTP over SSL/TLS) and the performance issues involved in deploying a website over HTTPS. What I understood is that the performance overhead in using HTTP over SSL/TLS is because of the use Asymmetric Cryptography in the Protocol and this overhead is highly dependent on the factors like hardware, server software, typical session length, caching behaviors of clients etc.

On the other hand, many of the recent articles like this one claim that because of improvements in capacity and performance of modern processors and their architectures, performance is no longer an issue while using HTTPS. Also, SSL certificates are no longer expensive as they used to be.

So, my question is, why are we still relying on HTTP when instead we can use HTTPS without any performance overhead on website? Is there any drawback of shifting all the communication over HTTPS?

Here are a few common reasons:

Certificate cost. Certificates typically are not free, and for small or otherwise less-important domains, the cost is not justified.
Virtual Hosting. While technology exists to specify a hostname during SSL negotiation, that technology is not widely enough deployed. As such, SSL domains require their own unique IP/port combination for disambiguation. And there aren't enough IPs to go around.
Caching. Edge-caching and content-distribution networks don't typically play well with SSL. This is more frequently true for third-party CDNs and proxy-based caching.


how does ASLR prevent return to libc / ROP and similar attacks? I am trying to understand ASLR and how it is implemented. I understand it does not actually "prevent" buffer overflow etc from happening, it will only make it more difficult. But i am not able to figure out how it prevent a return to libc attack. For example, lets say i have a program which has a buffer overflow. I give as input a np-op sled followed by shell code. The shell code overwrites the return address in the stack frame. So when the function returns it will execute the shell code. Similar if i write the address of a libc function that function will get invoked. now with ASLR, on every program run the program will start at some random address right ? but the libc functions are still at the same address and if I'm correct that won't change till i reboot a machine. So, if i basically try to brute force a vulnerable program with all possible addresses, can i still get a return to libc ? also, does aslr prevent ( and how ?) from ROP attacks ? if not what are the defenses ?

brute force a vulnerable program with all possible addresses

Trying to brute-force the address space (there are 2^64 possible addresses in a modern 64-bit system) is supposed to be impossible in practice due to constraints on time (and resources). Also see: What is the largest performed/possible bruteforce attack to date?

On a more practical note, if you guess the address wrong there is a big chance of the program crashing due to for instance a segmentation fault. Since brute-forcing a 64 bit address can take long, these crashes can be detected.

Therefore, finding the addresses of the shellcode on the stack, the library functions (in the case of return-to-libc) or the gadgets (in the case of ROP) is too hard for the attacker.

Of course, there are other ways to bypass ASLR. Look into Pointer Leaks and memory layout attacks such as heapspray if you are interested.


SSL/TLS certificates that only certain users can use to talk to my server are there something like SSL/TLS certificates or other equivalents which could allow only certain trusted users (from the internet) who have my server credentials in their browser to access my web server? How to go about doing this method? thanks

Client certificates?
Set your SSL/TLS-server to reject any connection that does not present a valid Client Certificate.
Related questions

2012-05-03: Advantages of client certificates for client authentication?