How to block users from downloading an attachment of a timed WordPress -post before article goes live? So I'm trying to solve how to block users from downloading an attachment of a timed WordPress -post before article goes live? Attachments work as uploads on a custom field in an article.

My current solution is to use htaccess to block the uploads archive, so visitors cannot browse them and thus see a new file before its released. Also if the client gives a hard-to-guess names to the attachments then users will not be able to get to them without knowing the exact name (right?)

.htaccess:

Options -Indexes

My questions:

On a scale of 1-10, how easy my current solution is to hack? Is it possible to make this solution relatively safe
Is there another safer solution for this? could a plugin be developed to transfer the file from a safe place when article gets released
Can ANY solution where the attachment is on the server/inside WordPress -uploads be a safe solution?
Is there a third party solution for this? Like service that could release documents at specific time

Thank you very much in advance

Your solution:

  Options -Indexes

It blocks the directory listing of files. The only way a user could find the attachment is if exact name of the attachment is known. This could be attacked using the following ways:

The Attacker uses a Directory exploring script or tool like Directory Buster. These tools contains dictionaries of millions of words, which are then bruteforced at rapid speed. If the attachment name matches with the word it will be displayed.
A pattern could be formed about the name of the attachment if the user observes the name of previous attachments, hence creating a custom wordlist to bruteforce.

On a scale of 1-10, how easy my current solution is to hack? Is it possible to make this solution relatively safe

Ans) It depends on the complexity of the names of the attachment.

Is there another safer solution for this? could a plugin be developed to transfer the file from a safe place when article gets released

Ans) Yes, a plugin can be developed, using cron jobs and wordpress development.

Can ANY solution where the attachment is on the server/inside WordPress -uploads be a safe solution?

Ans) This solution works , you just need to make your attachment file names a little complex. Means that avoid dictionary words, use special Symbols (" £ $ % ^ & * ( )<>?:@~}{) etc.

Is there a third party solution for this? Like service that could release documents at specific time

Ans) I don't think there is any, and there is no need to waste money on such services, as described above, if you follow this. hopefully it will work for you.


Is there a secure way to disable NFC and RFID on credit cards and personal IDs? If you're wondering why would I want that - it's for my own security: against identity and data theft.

Yes. Your issuer can disable transactions that are generated by NFC card. For NFC card, the Integrated Circuit Card (ICC) contains an additional secret key which generates cryptogram (Message Authentication Code) over the transaction data. If you ask your issuer to disable NFC transaction, it invalidates this secret key so cryptogram is no longer authorised.

They don't delete this key so that you can request to enable it again. Contactless payment can be still be processed by the terminal but the issuer responds with decline message. Source: My friend did it by contacting his bank and we tested it later. Transaction results in decline.

Regarding personal IDs, it depends on the usecase. For example, my workplace uses NFC smart card to enter into the workroom. To enter into the building, the only way possible is to let the terminal scan my ID card. The ICC is embedded which does actual authentication for NFC. If your organisation supports both physical (as a fallback mechanism) and contactless then yes they can invalidate authentication done by NFC. The only reason why would they do that is if they want to prevent NFC relay attacks on employees who have access to confidential area but want to maintain both mechanisms for the others.

Note that, the issuer can only invalidate transaction generated by NFC card. It cannot disable the NFC chip itself. Unless you tamper with NFC or shield it, NFC card can be used as normal. A fraudulent NFC reader can still read your passive card data.

You cannot disable NFC of ePassport as it is intended to be used that way by the authorities.

If you want your card or IDs not to be read, you need what some people call Faraday cage which they are not. Faraday cage is grounded. The foil that shields the card from NFC reader only reduces the strength of the signal and does not block it. High power crafted NFC readers can still read your card from distance. What you really need is a reflector that bounces back the signal as noise or a jammer which creates its own field to jam the signal.


Is it secure to use a hash of a login token as an anti-csrf token? Alright here is my proposal:

Use a hash of a login token as the anti-CSRF token.

Why this is a good idea?

Prevents having to store anything extra on the client, the server, and less network traffic as we don't need to transfer an additional cookie on every request
All the benefits of cookie based CSRF token
Login token still can't be accessed by JS (Its a non-reversible hash so we output the hashed login cookie in a meta tag, AJAX can still use it without exposing the login token
If login token is indeed unique per session (even between the same users) then each csrf token will be unique per session (minus collisions)

Is there any security problems I am missing? Obviously this would only work for pages where the user is logged in. But that shouldn't be an issue.

Btw by "login token", I mean a securely pseudorandom string that is stored on the server and on the client in the form of a cookie that allows the server to authenticate a user without them having to enter their password each time the page changes.

Ok so it was brought up that by using this method you are decreasing security ever so slightly because the hash is based off of the login token and you could brute force to find the login token. Even tho I think this is basically impossible because of how hashes work I propose the following solution. Split the login token into 4 parts, hash the 3rd and 4th using the 2nd as a salt. This prevent the use of rainbow tables and even if an attacker somehow brute forces, they will only have 3/4th of login token. Also, the salt doesnt need to be prepended to the csrf token itself because it can be derived using the login token.

Sure.
This is actually one of my preferred approaches. It makes the strength of your CSRF protection wholly dependent on the strength of your session token security, but session takeover strictly dominates CSRF in impact anyhow. The hashing means you can leave your session token in an HttpOnly cookie and not expose the session to JavaScript in any way.
However, drop everything in your last paragraph. Hashing only part of the token is strictly weaker than hashing the entire token. If you're hashing only part of the token, then brute-forcing that part is much easier (because it's shorter than the full token), and once you have a match you can not only launch CSRF attacks, you can also easily brute-force the last quarter (after all, you already brute-forced a string 3x as long) and take over the session. Salting is also meaningless in this context; the only value of a salt is to add entropy to the terribly predictable / repeatable strings people use as passwords, and if your token is fully random than what you propose would simply be taking out some amount of entropy and then putting it right back in, to no net benefit at all. You can't compute a rainbow table over possible 128-bit random token; every CPU and GPU on the planet working together would still take might-as-well-be-forever, and you couldn't actually store the table (even if some magical supercomputer could generate it) even if you turned every atom of the Earth into storage.
If you want a little bit of "feel good" security, you can HMAC the session token rather than just doing a simple hash. This is pretty pointless, though. Assuming the session token is already not at risk of brute force (because, if it is, you have WAY bigger problems than CSRF), any secure hash (I recommend something from the SHA2 or SHA3 family) is fine.
By the way, this works fine even with session token types other than the "secure random string stored in a cookie" approach. That approach has some of the problems that things like double-submit cookies try to get away from (it requires storing state on the server for each session, load balancing interferes with or at least complicates it, etc.) but this idea also works with things like JWTs. The main downside of the approach is if the session token changes (say, because a JWT was refreshed), the CSRF token changes, so you need to be careful not to reject valid requests for that reason.
Also, for what it's worth, login CSRF protection is a decent idea, on at least some sites. Anywhere a user will upload data that only they are to be allowed to see, login CSRF is a risk. Imagine a tax-filing webapp where you put in your highly-sensitive data into what you think is your own session, but somebody sneakily login-CSRFed your session to a session they have the password to. Then, after you've completed your tax return, the attacker logs in to the same account (it's theirs, after all) and downloads your returns.


How to Pass Authorization Header in HTTP Request when using HTML5 Player (Audio tag) for security i am using HTML5 audio player as follows :

<audio controls>
  <source src="<url>" type="audio/mp3">
</audio>

Now , i want to secure my app , So i want to pass some sessionId in Header parameter in http request for mp3 .

I could not find any way to do this , Please help if anyone knows the solution .

or

Is there any other player which gives this support ?

You cannot add any custom headers this way.

The established way to add user specific authorization is to have a session cookie. If such a cookie is set for the target URL (i.e. the user is already authenticated against the target) then it will be sent automatically within the request.

If instead the authorization is not specific for the user but instead some application specific access token you can include it in the URL. If you don't like that it is part of the URL and thus visible in the history you might behave as in the scenario above with the logged in user and cookie based session id. Only that you either set the cookie from within Javascript (in case of same-site request) or get a cookie for the target site by automatically "logging in" with your access token using XHR.

Yet another way is if the target sends a "authentication required" (HTTP status code 401) request back with an appropriate WWW-Authenticate header. In this case the browser will prompt the user for the login credentials and send these with each request to the site using the Authorization header.


Can SMBv1 be secure if used for just SMB server discovery? I noticed that my SMB shares from a Samba server no longer appeared in Windows 10 network browsing (network neighborhood) in Windows file explorer. The reason turned out to be that this functionality has originally been relying on SMBv1 to work -- which seems to have been installed and enabled by default as late as Windows 10 1703 -- but has since moved on to use WS-Discovery. Samba doesn't appear to support the latter.

What are the security implications of a SMBv1 client that only uses the protocol to discover SMB network services, without actually making a connection to a server? This blog post lists several vulnerabilities, but I don't know enough about SMB to determine whether they apply only to an SMBv1 client that is connecting/connected to a server, or if it applies even if it just sits there trying to discover servers without trying to connect.

DO NOT USE SMBv1.  It's been deprecated for so long that you actually have to manually enable it on Windows to make this work.  It's terribly slow, insecure, and exposes that host to exploits that have existed on the Internet for over 2 decades... DO NOT USE IT.

EDIT:

SMBv2 was a complete rewrite of SMBv1.  Every reference to higher order SMB "versions" is nothing more than a dialect of SMB2 (e.g. SMB 3.1 is just a dialect of SMB2).  As an example of the differences:

SMB1 sends one packet per file system command.  SMB2 sends multiple commands per packet.
SMB1 has over 100 specific commands.  SMB2 has like, 12 (that may not be entirely accurate, but the number is very low).

They are essentially different protocols.  Don't turn on SMBv1.  You're exposing your host to a whole host of vulnerabilities for the sake of a function you could get around by providing a drive mapping to the share.

Final Edit to Address the OP's Edits:

The problem with SMBv1 is SMB Relay Attacks and ultimately the attacker harvesting credentials using it.

Windows provides a way to require digital signing of network communications, specifically related to SMB communications.

Set this policy to enabled for all SMBv1 communications in local policy or group policy:  Microsoft network client: Digitally sign communications (always)

This will likely break access to your SAMBA server unless you can configure it to also digitally sign SMBv1 communications.

FWIW, and if I hadn't made it clear, I don't recommend using SMBv1 in light of its inefficiencies and insecurities.  The minute you misconfigure this on a single host, you've enabled one of the most commonly exploited vulnerabilities that exist today on a network.  Good Luck.


There seems like a wide gaping hole in the process for checking integrity of e.g. linux distro releases Many Linux distributions (e.g. Fedora) recommend using downloaded signing keys to verify the integrity of downloaded checksums. This seems utterly ridiculous to me, since the downloaded keys are just as suspect as the downloaded checksums. And checking key fingerprints is exactly the same thing, i.e. the page with the fingerprints is just another file downloaded by my browser.
If I trust the PKI of my browser (assuming HTTPS) to authenticate the key or key fingerprints, then I don't need the signing process in the first place. But of course I don't trust the PKI because the list of root certs distributed with major OS's is chocked full of very very dodgy CAs.
At minimum, shouldn't the keys of a new release be signed with the keys of the previous release? That way you can maintain a chain of integrity.
Given that the same process is used for GPG I assume I am being a moron and missing something obvious. Can anyone explain?

In short, the TLS PKI used in HTTPS and the packet signing with GPG aren't complementary layers of security in this context, but against totally different risk models.

Getting the public key over a secure channel. You get the public key from a trusted source, in this example over HTTPS from https://getfedora.org/static/fedora.gpg, where getfedora.org is the official site of the distribution, and the connection is encrypted using PKI validated certificate.
If in doubt, you could minimize the possibility of MitM by accessing the site from a trusted location (not e.g. over public WiFi) and by examining the certificate and the connection details manually. It's also possible to cross-check the details with some external diagnostic tools like SSL Shopper's SSL Checker, DigiCert's SSL Installation Diagnostics Tool or even Qualys' SSL Server Test. If the details match, it's unlike someone is intercepting your connection with a fake certificate signed by a trusted CA.

Getting the packages over insecure channels. Signing the packages allows a wide distribution network, while the official distribution still has full control over the contents. This addresses two security problems:

The packages aren't typically downloaded directly from getfedora.org, but from multiple mirrors from all over the world. The mirrors aren't directly controlled by the Fedora project, and it's possible someone running a mirror could act maliciously or be compromised. (Of course, getfedora.org could be compromised, too, but having multiple mirrors multiplies the chances, and constantly monitoring them all would be impossible.)

Furthermore, some of the mirrors are used over plain HTTP (and sometimes FTP), which leaves possibility for MitM attacks.


SSL Decryption why is the root CA certificate required on clients? Maybe a quick question. We have Palo Alto's that perform SSL Decryption using a sub CA certificate issued by our internal Root CA. This is working for our internal windows domain computers as the root CA and sub CA are pushed down to all of them via Group Policy. My question is we have a few Mac users that GPO doesn't work with, so they will manually need to add the certificates.

My question is, if the subCA installed on the Palo Alto (doing Dynamic SSL generation for sites), is also installed on these Macs. Why are the users still getting untrusted connection detected in their browser? It complains that "This certificate cannot be verified up to a trusted certification authority".

If I install the root CA certificate additionally, they no longer receive errors. Hooray!

However, my question is why do clients need the root CA if the sub CA(on Palo Alto) was the one that generated the explicit certificate(such as bankofamerica.com, etc).

The reason is that most cert stores do only treat CA certificates signed by itself as root certificates. SubCA certificates will in most cases be added to a store called "intermediate certificate issuers". This store does not add any trust to the certificate, its only as a convience to the computer in case the server only sends its own cert, not the intermediate certificate that links to the root.

(some misconfigured server might send only cert (A) of (A)-(B)-(C). If the (C) is in root store, the computer wont be able to complete the chain and would complain on (A) being untrusted. Thus (B) is added to the intermediate store, which is not trusted, but adds the link between (A) and (C), making (A) trusted. The reason its unsafe to trust (B) automatically, is that (C) might get revoked and any linked certificate must revoke too)

Any certificates in the "intermediate certificate issuers" must chain up to a certificate inside the trusted root store to be trusted.

But in most certificate stores, it should be manually possible to inject a certificate in the root store even if it not signed by itself. Sometimes, you must check a checkbox that you want to install the cert manually, sometimes you need to manually wander in the stores and add the certificate using a button


What are the pitfalls of repeating a password multiple times for increased length and entropy? Many of us are familiar with this comic. If I had a word like "catfish" and just repeated it an arbitrary amount of times, say n, it would be theoretically stronger. Wouldn't it?

One pitfall I could see is dictionary attacks with multiple values of n but it seems like this might not be ideal. What if picked a more arbitrary string like "ca4f1sh!"?

The problem with picking a password based on any pattern is that, if the attacker knows the pattern, they can then eliminate relatively large numbers of possible passwords they'd otherwise have to test.

This is why we advocate for passwords to be randomly-generated as much as possible. The only restrictions you might want to put on the random generation are:

Minimum character length
Inclusion of multiple character types

Those help to ensure (though, strictly, not guarantee) that the random generator will not unintentionally spit out a password that's likely to be found in dictionaries or rainbow tables. However, where it can be avoided, we do not want to add in restrictions like these:

Maximum character length
Exclusion of certain characters or character types
Matching specific patterns (e.g.: a dictionary word repeated n times - even if n is random)

These will greatly reduce the search space for an attacker who knows your password generation scheme. You might still be able to dodge the ones who are just looking through a database for passwords they can easily break. But you'll be much more vulnerable to a dedicated and resourceful attacker who is targeting you specifically (some call this an "Advanced Persistent Threat" or "APT"), or if your particular method becomes common among other users and the large-scale attackers adjust their methods to compensate.

True random generation of passwords, with very few restrictions to avoid accidental output of weak passwords, is the only way to be sure your password is strong enough to resist virtually any attacker. Of course, this all does assume that the password storage and transmission mechanisms are reasonably secure as well - but that's beyond the scope of this question.

In short: A password based on a single string repeated a number of times, is always more vulnerable to a dedicated attack than one which is of equal length and randomly generated throughout.


Human readable SSL/TLS packets If I have a protocol-analyzer/packet-sniffer, such as wireshark installed on a particular device..

(or in this case; tcpdump & tshark etc. on my smartphone..)

..should I be able to read that devices incoming & outgoing ssl/tls traffic, in an unencrypted/decrypted state?

don't know about the smartphone case, but with Wireshark, as long as you own the key you can.

Here you have a video doing all the walkthrough and here a Wireshark wiki post about it. Basically you need to go to the preferences of the SSL protocol and put the key file.


How can I track someone logged in my gmail account over imap? Gmail tells me if someone new logged in to the web-interface (device, browser etc.)

But what about IMAP logins?

If someone has my password can he stealthy read my mails over IMAP?

Yes if you don't have two-factor.

No if you do.

If you enable two-factor, then the IMAPS connections require a generated app password which you can only get by logging into your Google account profile and generating online.  You can't set these passwords, but you can leak them so be careful not to store them beyond what the email client requires to function.

Disabling POP and IMAP is the best mitigation.  If you really need IMAP then two-factor is a good mitigation. Two-factor is good to enable either way.


What questions should be asked when joining a new security team? I've accepted a position at a different company working on their security team and have been mentally putting together a list of questions to ask so I can rapidly get up to speed in the environment and start gathering ideas about things to prioritize.

A lot of what I'm thinking of is based on http://www.opsreportcard.com/section/28, but surely there are others. What are your go-to questions to ask when onboarding in a new environment?

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


How do websites track users for flow control I've written a short program that uses a webbrowser to visit many pages of a website (on which users can sell/buy items - kind of like a specialist ebay). However after 20 or so page views I get directed to a flow control page - "you've made too many requests recently".

I don't actually have any issue with spreading out my requests, this is for a pet project nothing commercial. However I figured I'd try and bypass it so I can be sure I don't miss pages (my plan is to do exactly 20 pages every hour which at the moment seems to be below the boundary). At first I thought it might just be cookies, so I deleted them after each request. The I thought it might be something to do with the last page I was on (ie. I move to page 2 and it knows I've come from page 1 etc.). so I sent the webbrowser control to about blank and in between requests (no success here either).

So how does a website track users for flow control purposes? It can't be IP based because I can still access the site using a different browser (chrome as opposed to an embedded IE).

There's many ways to enforce request rate limit, so I'll mostly focus here on what appears to be going on in your case;

It's highly unlikely, considering it's a commerce site, that you're dealing with such an anal retentive IDS (Intrusion Detection System) setup to block anything that remotely looks like a crawler and blocks (redirects in your case) requests on network level. Even though such systems are capable of request rate limiting, on sites like you describe, those would be setup a lot more permissively and only try to prevent illegal requests, request flooding, and similar. 20 GET requests per hour isn't that.

What's more likely going on is that you've hit a pesky WAF (Web Application Firewall) which acts on the application level and would care to fingerprint your browser and compare consecutive requests to establish if you're a crawler, then flag your requests as suspicious if they follow certain pattern that it is setup (or even trained, if you're dealing with a heuristic WAF) to detect. Such as, say, requesting many subsequent pages in the same order as they appear in the source, but are missing this source page (or the domain alone in case of HTTPS) in the GET request header's referer [sic, it's mispelled in HTTP specs] field. This would happen if you scripted your browser to request each new page independently, as if you typed its URL in the address bar and pressed enter, and is one of the safest methods (low chance of false positives) of detecting automated crawlers (aka bots), especially if you repeatedly request long and messy URLs and they otherwise use human readable versions of URLs, or ones equipped with additional URI parameters (referrer schemes, user tracking,...) in emails and everywhere else where users might access more of them in a short period of time without opening them through some landing page.

In short, if you'll want to avoid this detection of automated crawlers, you'll either have to inspect and obey rules in their robots.txt page, request from site admin to lax the rules for your crawler and make sure they can easily identify it (such as through user agent string), or make your script such that it mimics a human user better. Penultimate paragraph should help you avoid one of the most common bot detection techniques that seems to apply in your case, but you might hit additional ones as your request rate increases.


EV SSL vs TLS - which one is an advanced version I understand SSL is the predecessor of TLS. What about EV SSL? We are using a payment gateway that is rolling out a change soon and will require TLS1.1 or higher. We are currently using a SSL from Godaddy and they said that if we want to upgrade the highest they have is EV SSL. Wanted to understand if EV SSL is equivalent to TLS1.1 or lower.

I think there's a mismatch in terminology between the SSL/TLS protocol (messages sent over a network) and SSL Certificate Authorities who issue digital certificates to be used with TLS/SSL and / or other crypto protocols.

SSL/TLS

You are correct that SSL is the pre-cursor to TLS. This refers to crypto configuration in your server with higher versions indicating more modern crypto:

SSL 1.0 (obsolete)
SSL 2.0 (obsolete)
SSL 3.0 (mostly obsolete)
TLS 1.0
TLS 1.1
TLS 1.2

These are settings you configure in your webserver, and govern which crypto a browser will use when connecting to your server. You do need a certificate for your server in order to enable SSL/TLS, but for the most part, any certificate you get from a CA can be used with any version of TLS.

SSL Certificate Authorities

A Certificate Authority issues certificates for use with TLS and / or other crypto protocols like S/MIME email, signing PDF documents, etc. Most CAs market their "web server" type certs as "SSL" rather than "TLS" for historical reasons. Most CAs offer various price points of certificate, usually broken into:

Domain Validated (DV)
Organization Validated (OV)
Extended Validation (EV)

This refers to how much time their humans spend doing background checks to ensure that you do in fact own the that web site that you are requesting a cert for. They check things like: can you post a file they provide somewhere on the site? Does the DNS record for that domain list you as the owner? If the DNS record lists a company, are you in fact an employee with authorization to request certificates on behalf of that company? And so on, with DV certs just doing the automated "can you upload a file?" checks, and EV sometimes requiring face-to-face meetings between you and the CA, and original hand-signed documents from the CEO.

Consequently, browsers display bigger, greener lock icons for EV to indicate to users that the browser is extra confident that this is not a phishing site. (EV certs are where you see the legal name of the company as part of the TLS lock icon). Note that bigger greener locks have nothing to do with the type of crypto or version of TLS used.

Bottom line: The level of certificate you buy (DV, OV, EV) and the version of TLS that you configure your server for (SSLv3, TLS1.2, etc) have almost nothing to do with each other. All levels of certificate use the same type of cryptography, and and all certs are compatible with all versions of the TLS protocol.


Use THC hydra to make dictionary attack on localhost I have programmed a log in in my webpage and now I want to test it against a dictionary attack. I am using Apache and my website is not online so to access it I connect to localhost/website In hydra I am using the command

hydra -l username -P passList.txt localhost/website http-post-form "/logIn.php:user=^USER^&pass=^PASS:forgot"

But it terminates with error

[DATA] attacking service http-post-form on port 80
[ERROR] could not resolve address: localhost/website
0 of 1 target completed, 0 valid passwords found
[ERROR] 1 target did not resolve or could not be connected

What could be the problem?

It looks like the problem is here localhost/website This command should do the trick hydra localhost http-post-form "/logIn.php:user=^USER^&pass=^PASS:forgot" -l username -P passList.txt


Is refresh token nessesary with HTTPS I fully understand the benefits of refresh token in the case that Access Token gets compromised.

I send JWT access token to the server only through HTTPS for a mobile application and web application that needs lifetime login. So I believe the access token cannot be compromised unless user's device is in the attacker's hands. Again if user's device is with the attacker's hands then both refresh token and the access token would be compromised.

Is there any other way to compromise access token ? If NO, In my case, is it necessary to have refresh token system ?

UPDATE 1 :  I use only single server. No seperate authentication server and resource server.

One major difference between Access Tokens and Refresh Tokens is who gets to see them.

The Access Token is handed out by the Authorization Server, and is then used by the client to gain access to the Resource Owner's resoures. The Access Token is seen by both the Authorization Server, the Client and the Resource Server.

The Refresh Token is handed out by the Authorization Server, and is only seen by the Client and the Authorization Server. The Resource Server never sees the Refresh Token.

So, the Access Token is more vulnerable; it is seen by more parties. A sloppy implementation on the Resource Server could lead to the leaking of the Access Token, while the Refresh Token would still be safe.

Credit: I had some help from this Stack Overflow answer writing this.
One scenario it mentions is that the Access Token might be sent as a query parameter, and then end up in a log file. The Access Token was protected by HTTPS during transit, but is now in the log file on the Resource Server. People who are not entitled to knowing the Access Token, might be entitled to see the log file. For example, students having a summer job as tech support.

What's important, though, isn't to try and invent a specific scenario in which things might go wrong. What's important is to realize that the Access token could leak with the Refresh Token still being safe. It's a form of defensive programming - be prepared for the case that there is a vulnerability in the Resource Server.

Since in the given situation the Authorization Server and Resource Server are a single application, most scenarios where the Access Token is compromised will also have a compromise of the Refresh Token.

As a side note, I've worked on a similar scenario. We used Identity Server as the Authorization Server. It was built into the application. If that application leaked, I would look to the Resource Server part first. Identity Server is built by security experts and, being Open Source, has been scrutinized by many. The Resource Server part of that particular application was proprietary. You may want to look at Identity Server for your application as well.


Does verifying identity by positions in passwords mean passwords are stored unhashed? If authentication occurs by asking the user for the characters at certain positions in the password (such as: give the 3rd and 7th character in the password), does this imply that passwords are stored unhashed?  Or are there safe hashing techniques where it is possible to verify the hash of a subset of the password against the hash of the entire password?

It is possible that the service not only computed the hash of the full password when it was created, but also hashed the 3rd and 7th character (or possibly every character) individually. That way, they technically wouldn't be storing the characters or the full password in plaintext. However this would be a terrible idea. A hash of a single character is essentially no better than plaintext since there are only perhaps 62 possible single character hashes per salt (if a salt is used).

Either way, if the service has the ability to recognize part of the password as opposed to only the full password it is bad news.


Getting infected from gmail login Is there any way at all to get malware or a RAT just from logging in to your gmail account. Not by opening attachments or clicking licks, just from logging in. And I mean real gmail, not a phising attack.

It would be in theory possible that google gets infected and serves malware, although I consider this highly unlikely. More likely is that such an attack is done by malicious browser extensions or attacks through advertisements (malvertisement), i.e. things which are outside of the control of google. And of course a man in the middle attacks might be possible too, especially if you have already one of the known bad certificates on the computer or have an ad injecting software installed.


How secure is Vigenere cipher for random data? Traditional situation

It is easy to crack a ciphertext encrypted by Vigenere cipher, if you know the plaintext is in a natural language like English. There are two methods to discover the key used to encrypt the plaintext. Either you know frequencies of certain characters that will occur more often than others (e for English) or you know a word that will occur in the plaintext (the, a, etc. for English).

Cryptographically secure random

What if the plaintext is actually CSR (cryptographically secure random) data, and you encrypt it using Vigenere cipher with a CSR key.

Let's say we reuse the key four times (to account for flaws if random is not CSR?). Also, the key is sufficiently large so that brute forcing it is not an option (for example, the key may be 1KB, and therefore the cipher and plaintext is 4KB).

Would it be possible to crack that, even though you are reusing the same key (the key is also CSR) but not as large as the plaintext data?

or: how secure is this relative to other methods for encryption/decryption?

Context

In case you ask yourself: 'why would you want to encrypt random data?':

Well, if the answer is no, and thus it is impossible to crack it. That would mean that once a shared secret is established between two persons, you could establish an information-theoretically secure connection, right? Because once you have a shared secret key 'A' of 1KB. Then you could create a shared secret key 'B' of 2KB using 'A' two times on newly random generated data. Then you could use 1KB of 'B' as a one-time pad on your actual plaintext communications in English. And you could use the other 1KB of 'B' for safely communicating the next 2KB sized key and so forth.

I agree it would be difficult (possibly impossible) to break a Vigenere cipher on random data that's never used and is simply random.

But your scheme where you use that random data as a one-time-pad would not have informational theoretic perfect security like a one-time-pad.

It will have the security of a Vigenere cipher -- the weakest link in the chain.  You wouldn't be able to easily directly attack the Vigenere cipher on the random data, but you could easily attack the combination.

I mistakenly misremembered the Vigenere cipher with its primary operation being XOR not addition modulo character space.  My mistake makes the attack on your scheme trivial due to properties of XOR.  I'll call my mistaken scheme VigenereXOR.

The old example using VigenereXOR:

 import scipy
 rand_bytes=[scipy.random.random_integers(256) for i in range(512)] # 512 random bytes
 vig_key = "MYSECRET"*64
 vig_key_bytes = [ord(c) for c in vig_key]
 encrypted_random = [(r ^ vk) for r,vk in zip(rand_bytes, vig_key_bytes)]
 message = "But your scheme where you use that random data as a one-time-pad would not have informational theoretic perfect security like a one-time-pad."
 message_bytes = [ord(c) for c in message]
 encrypted_message = [(r ^ m) for r,m in zip(rand_bytes, message_bytes)]

Now if an attacker observes both encrypted_random and encrypted_message, they can XOR them together, at which point they would have the original message simply encrypted with the Vigenere cipher as (A XOR B) XOR (B XOR C) = A XOR C; hence all the frequency attacks on the message Vigenere could be directly applied.

On the real Vigenere cipher:

 encrypted_random = [(r + vk) % 256 for r,vk in zip(rand_bytes, vig_key_bytes)]

there may be sophisticated attacks on it.  At the very least you obviously do not have perfect security from the scheme.  If the scheme had perfect security, then the length of the Vigenere key would be irrelevant and it obviously isn't -- a one character key could be used -- which would be trivially attackable.  You may note that you can still construct (A + B mod 256) XOR (B XOR C) = ((A + B mod 256) XOR B) XOR C.  (A + B mod 256) XOR B is not randomly distributed (e.g., if A = 8, then the only possibilities for (A + B mod 256) XOR B are 8,24,56,120,248 after trying all 256 values of B).  Headway of this sort possibly can be made to make this attack much better than brute force.

It's a common textbook result (with a straightforward proof) that you can't get information-theoretic perfect security if your keyspace (what was exchanged prior to encryption) isn't at least as large as your message space.  See Shannon's classic 1949 paper.


Virus / malware stored inside database I have a small network of several Windows 10 machines (all protected by BitDefender 2020 Total Security), one of which acts as server with Firebird database.
For some time the database is deteriorating - in some random records some fields have altered values.
I completly changed the server machine for a brand new with fresh Windows 10 installation and antivirus, on which the database was recreated from GBK archive.
The primary machine was carefully check for RAM errors (with MemTest86) and SSD errors (CrystalDiskInfo and ADATA SSD ToolBox) - everything was in 100% fine.
I don't have no suspicions other than that the server was hacked, but it looks like an alleged malware / virus must move inside database (even packed GBK archive), because only GBK file was moved to new machine (on verified pendrive).
Is it even possible that the virus is stored inside the database (e.g. in the form of stored procedures, etc.) and it transfers with GBK archive?
If so, how to detect and remove it from database?
(Firebird database is stored in the form of single FDB file, which was scanned by BitDefender without any results)

In general the answer to “is it possible” will almost always be yes.
In the case you describe: is it practical that something malicious would be stored in the database? It seems unlikely, and wouldn’t be the first explanation I’d choose for the circumstances.
If you are particularly concerned then lookup historic vulnerabilities in the software, a typical search might be “firebird CVE”.
Some further ideas:

Assessing whether there are any suspicious saved functions should be trivial. Use a database manager and inspect any stored procedures.
Dump the entire database to a “safe” format and check the data   matches the expected format. For example, backup to ASCII SQL statements and restore to a fresh database.
Leave the database running for some defined period without making any changes (for example prevent your application from updating or inserting rows). Does the corruption still occur?
Turn on query logging, if possible. Do any statements affect rows which then become corrupted?
Check your application code carefully! A logic bug is a far more obvious cause of this kind of problem.

These ideas assume you are using the latest version of the database software.


Do I need strong user password for an encrypted VM? I've just imported Whonix VirtualBox VM, and have encrypted its drive via VirtualBox settings. Now when I booted it, the default credentials are "user/changeme", and setup suggests I change the password. I am not sure if I need to change the defaults.
If the VM itself is already encrypted, does setting complex user passwords make the system any more secure? I am the sole user of this computer, I only care if someone uses it in my absence.

What you are asking for is a risk assessment. A strong password protects you from something. You want to know if you need to be protected at all. We can't know all the possible threats against your system, but the risk model is easy to discuss.
Default credentials are like not having a password at all. So, if you start from that point, what impacts might there be if you didn't have a password?

someone with access to your machine could log in easily and gain access to whatever that user has access to - but if there is nothing of value, then your risk is minimal
if you set up remote access, then any remote user would have easier access to the VM - but if there is no remote access, then there is no risk

Strong security is always great, but security secures against a threat. If there is no threat, then there is no need for controls to mitigate that threat.


How to secure an open wifi access point I have seen tremendous amounts of guides on how to protect yourself when using a public wireless internet connection, but nothing about how to protect your public access point from malicious users.

A bit of background. I had bought this raspberry Pi and still nothing useful to do with it, and a spare USB WiFi Dongle(with an antenna). So I decided to share my internet connection when I'm not using it. So i have installed hostapd, use dnsmasq for dhcp, a squid proxy server (transparent with iptables redirecting port 80 to 3128). Note here that i'm aware of how short the lifetime of my SD card will be. Another point you should not consider is bandwidth usage consumption, since I have setup QoS on my gateway and hve unlimited internet (standard here, in France)

What I'm concerned about is I have no idea of what kind of security policy I should setup to prevent, say, someone to inject a malicious program inside the raspberry pi which will then infect not only every new client on the Wireless subnet, but any computer I have plugged to the local LAN.

I also feel concerned about how to protect any connected host from another malicious wifi user. Having had the same concern once at work, all I thought about would be ARP poisonning every host saying them any MAC address different from theirs is the access point, but that seems overkill and inefficient.

Here are my ideas:

Block port 443 on any connection
Install SquidGuard to enforce authorized/unauthorized websites (I tried, too CPU-intensive for a RPi)
Restrict interactions on the local network (except the internet gateway) to SSH from my computer and HTTP for my monitoring tools

What I already have as a security measure :

non-standard passwords for local users
sshd not listening on wireless interface
httpd not listening on wireless interface
Regular backups of my squid logs on an offline media in case any legal source asks for them ?

So, what else should I set up, according to you?

A public access point is public. This means that anybody can connect to it and use it. Thus, "protecting the access point against malicious users" is not a well-defined goal. The access point has no secret data to keep confidential, or a restricted service to offer only to authorized users. It is public.

What you might want is to protect users from each other: you don't want one user of the public access point to be able to eavesdrop on other users, or alter their data, or even simply disrupting communications. This is a problematic of big sites which really want to provide "free WiFi" for a lot of people but have a recurrent problem of antisocial users.

It turns out that you cannot. The cryptographic elements in the WiFi protocol are meant to:

Enforce authentication, keeping people out of the connection if the access point is not public, but requires authentication.
Prevent eavesdropping on the connection of duly connected users from people who are not connected.

However, nothing in the WiFi protocol was designed to prevent two connected users from spying on each other. With a public WiFi, everybody can connect (by definition), so everybody can spy on everybody.

Crippling your access point, e.g. by blocking port 443, won't bring any security, except in the following sense: if the access point is made unusable because of too strict restrictions, then people won't use it, and thus the spying issue disappears: there is no attacked user if there is no user at all. But for the remaining users, blocking port 443 just makes their situation worse: not only does it not prevent other users from spying on their traffic, but it also prevents them from defending themselves by using HTTPS browsing when possible.

You seem to be aware that "legal sources" may ask for logs. The legal situation is actually worse (for you):

By willingly running an open access point, you have become a service provider, so you are bound by all the regulations attached to that state. The ARCEP could give you the relevant information, but be warned that this goes much beyond simple squid logs.
Your own Internet access was provided to you based on a contract which explicitly forbids sharing beyond "home usage". If you act as a service provider (that's what you are trying to do), then you are in clear violation of the terms of that contract, and your ISP may lawfully shut your access down.
If someone uses your access point to then engage in "illegal activities" (e.g. attacking other sites) then you could be considered as accomplice. That's the point of the ARCEP regulations: registered service providers can claim exemption, in the way that phone companies do not get into legal trouble when criminals plot crime by phoning each other. This exemption is not automatically granted to just any random citizen who plugs a WiFi access point.

Therefore, running your own public access point, just like that, really is a bad idea, however generous the basic principle might seem at first look.


Why would DB with URL access be less secured than without such access? I've heard that DB with URL access (as with PHPmyadmin) would be less secured than without such access.

I'm not an IS expert and doesn't work in the field but I can't see how this saying be true; Why would this matter? In any case, anyone can access the DB locally for software like Workbench or Navicat, if it has the right credentials...

It's not necessarily inherently less secure, just often practically.

In the first place, adding more software adds more things you have to secure.  Phpmyadmin has had its share of vulnerabilities, and now you have to worry about those in addition to the MySQL ones you had to worry about before.

One fairly standard thing to do with MySQL is to limit the privileges of accounts to only accept logins from a small whitelist of IPs (for a small app, that can be just localhost).  But as soon as you install Phpmyadmin, you've provided a proxy of sorts for MySQL access from anywhere - unless you take extra steps to lock that down as well.

Web interfaces like this can be set up securely, but they just add another administrative tool that you need to secure; if you learn how to use the commandline mysql over ssh, then you can eliminate one entry point for an attacker.


Benefits and drawbacks of giving an Administrator two accounts for elevated rights and another for daily use, such as email Microsoft has long promoted the need to separate administrative accounts from regular use accounts, as shown with this guidance

MSFT even went to far as create ADMINSDUser rights to put administrative accounts in a separate "class" than regular accounts.  They intentionally made it tough to be both an "Administrator" and a user of Activesync

I'm sure none of these design decisions regarding separation of administrative duties were made lightly, or without the input of several smart people.

My question is:

  What bad habits can an Administrator do that cancels out the benefit
  of having dual accounts?

  ie: checking email
  casual surfing the internet, versus surfing the internet to troubleshoot, diagnose, or validate an issue

  What are we protecting ourselves from?

  If an Administrator knows they may be visiting a hostile website, they are probably smart enough they should be testing this on an isolated network/machine
  Administrators usually aren't tricked into running scripts, or hostile code (ActiveX) that other users may be

Suppose a person's daily job is administration, and deals primarily with troubleshooting using their privileged credentials.  It seems self-defeating and unproductive to ask them to "RunAs" for every new task.

Taking the last idea a step further, perhaps it would be better to RunAs for non-administrative tasks, such as email, file and print services, etc.  Maybe they should use a virtual machine, VDI, etc to check email and update network diagrams (etc).

  3   . Does it make sense for an Administrator to use his privileged credentials for signing into his PC, and using RunAs for non-administrative tasks?

Surfing the internet is a risk to an organisation - usually this is mitigated to some extent by having limited functionality for users, so an exploit is limited in what it can do. When an administrator is doing the surfing his account is not limited, so an exploit can have major consequences.

  If an Administrator knows they may be visiting a hostile website,
  they are probably smart enough they should be testing this on an
  isolated network/machine

Sadly this isn't true - admins are people too

  Administrators usually aren't tricked into running scripts, or hostile
  code (ActiveX) that other users may be

There are attacks already out there that require no interaction other than browsing to a website, and as I said, admins are people too (mostly)

  Suppose a person's daily job is administration, and deals primarily
  with troubleshooting using their privileged credentials. It seems
  self-defeating and unproductive to ask them to "RunAs" for every new
  task.

For this, you could argue the case for separating by machine, rather than by account - ie all the admin tasks are carried out on an admin machine which can't connect to the internet etc., and the user type tasks are carried out on another one which can.

  Taking the last idea a step further, perhaps it would be better to
  RunAs for non-administrative tasks, such as email, file and print
  services, etc. Does it make sense for an Administrator to use his privileged credentials for signing into his PC, and using RunAs for non-administrative tasks?

RunAs downwards is just susceptible to the admin forgetting, or just wanting to do something quickly and easily.


Are there any tools to detect JavaScript-based WCF/AJAX calls? I'd like to determine if a given JavaScript contains the logic to make a AJAX/WCF call, or determine if one is being executed at runtime.

Does anything like this exist?

Im using Firefox plugin called JavaScript Deobfuscator. This works very well as Im able to see all scripts that are compiled and all executed scripts. This updates on the fly, and contains good details on all the executed scripts.

You can also use filters to only capture javascript on a given domain. This plugin has helped me a lot in web pentesting.

You can find it here https://addons.mozilla.org/en-US/firefox/addon/10345/

Quote from the plugin page:

This add-on will show you what JavaScript gets to run on a web page, even if it
is obfuscated and generated on the fly. Simply open JavaScript Deobfuscator from the
Tools menu and watch the scripts being compiled/executed.


How to perform safe authentication via HTTP? I have to log in on an HTTP website.

There is a login form which contains inputs for username and password and as hidden inputs the sessionId. I am creating an application in which I have to access resources which just can be accessed if you are logged in on this website, so I provide a username and password input in my application to log in.

I watched the HTTP requests now, and the HTTP POST request in which the login data is sent has the parameters password and username, so I could see my username and password in Fiddler non-encrypted, but I don't want to send my data unprotected.

If the parameters of an HTTP POST request can be seen by tools like Fiddler in the clear, does this mean that my data is sent without any encryption to the server? Or is there any kind of encryption that is done which just isn't visible to me?

Ordinary HTTP of all sorts is unencrypted.  If you want to protect your data, it has to be sent over HTTPS.


HTTP Basic auth password storage more secure than Digest auth If you are using SSL already, it appears Basic auth is the way to go since you can perform bcrypt with the password when you store it in the database, where as Digest auth only allows md5. As we know, in case of database theft, md5 can be "cracked" faster than bcrypt.

My question now is, given SSL is present, and the fact you can't bcrypt Digest auth passwords, why would I still want to use it over Basic auth? Or is Basic auth the way ago if there is SSL.

BTW this is for a REST API server

The choice isn't just between basic auth and digest auth if you are using SSL.  Digest auth is preferable to basic auth if you have no SSL, though still leaves you a bit vulnerable to man in the middle attacks; though it makes it them more complicated than basic auth.

However, I'd avoid basic auth for several reasons:

an ugly interface to login (a barely configurable pop-up alert when you first go to a protected page) versus an optional login form somewhere on the page.
on a bad login attempt, 401 - Unauthorized messages are worse than a customizable wrong password screen; where maybe you add a CAPTCHA, or have links that could remind username based on email address, or reset a lost password, or create a new account.
You generally can't log out of Basic Auth login without closing the browser.

For this reason, I'd recommend using cookie-based sessions (over SSL) for those reasons, where again you use a strong hash (e.g., bcrypt) to store the password.


Is there an other place than the changelogs to see if a debian package is corrected or not? I would like to know if there was an other place to see if a debian package is fixing a CVE than the changelog of the packet. For instance the packet bind9 1:9.7.2.dfsg.P3-1 is fixing the CVE-2010-3613 here, can we see it somewhere else? To be more specific, can we see it in a place where we can compute the reading ?

Debian provides a feed for its security advisories: http://www.debian.org/security/dsa. There is a link to each advisory which lists the CVE addressed by that fix. The debian-security-announce@debian.org mailing list provides the same information. These advisories have been declared CVE-compatible. The email and RSS feeds are the most timely way to retrieve advisories. See the section on security advisories in the manual for more context.

Additionally, Debian publishes an advisory cross-reference which lists all the advisories with the CVE that they address (as well as Bugtraq IDs, CERT advisories and US-CERT vulnerability notes). MITRE also publishes a CVE reference map listing CVEs addressed by each DSA.

I don't know of any “official” place where you can retrieve the CVE-to-package-version map in a single go. From the Debian cross-reference, you need to follow the DSA links to know what package version brought the fix.


SSH and shared secrets There was a question on a quiz I took, about different authentication methods that SSH uses.

The answers were combintions of the following four:

username/password
public key authentication
shared secret
kerberos authentication

I choose the answer which included all four, but I wasn't sure if shared secret is actually used. Here it says that it can be.

Can someone explain this to me?

The link you've provided does not mention SSH at all.  SSH can be easily configured to use username/password and public key authentication.  Major SSH implementation allow for the configuration of Kerberos authentication.  But SSH does not allow the use of shared secrets for authentication.  The protocol itself just doesn't support it.

SSH isn't really designed for using shared secrets.  Shared secrets are often used for long term VPN tunnels between two end-points.  While you can tunnel with SSH it is designed to perform secure shell actions.  For this you would like to authenticate individual users so that admins can keep track of who is connecting to a particular machine.  Shared secrets would only authenticate the machine that is connecting to it, not the user.


Can FIDO be implemented for a Use Case which Allows the Use of Shared Devices? I am a part of an organization that is developing a website that required user authentication, and we are strongly considering FIDO compliance.
However, our use case requires users to be able to log-in from shared computers (i.e. father and son may share the same computer). And we cannot expect our user to carry around a FIDO authentication token (U2F key) as well.
In such a scenario, is it safe to use on-device biometric sensors (i.e. cameras, fingerprint scanner) on a shared device to authenticate multiple users?

I do not know of any build with FIDO compliance. Furthermore: you have no control over what webcam/fingerprint sensor/... the users are using.
So, FIDO aside, is it safe?
The answer is simple: you have no control whatsoever over the computer that is used to access your website (might be a Win10, might be a Kali). If you make devices that you cannot control part of your chain of assurance, it is not safe, unless you take additional measures.
Furthermore: you will require your users to give your website access to their webcam. That may be acceptable in your users community, but it certainly is not acceptable in ours. That is something you need to consider too.


Will brute force attack exhaust web server, resulting in DOS I do know the difference between brute force attack and DOS.
What if a web server doesn't have account lock out in place and a few brute force attacks is being started in parallel, and these attacks will keep web server CPU intensively busy. Will these attacks in the end reduce the abilities of web server to serve other legitimate requests and result in a DOS attack?

YES INDEED
I used to own a shared hosting business and, while being at a party on a weekend night, I received an automated monitoring notification triggered by a resource exhaustion. I immediately left to the office and when I arrived I found out a bruteforce attack against a client's WordPress admin panel was the cause of it.
Always make sure your firewall rulesets are up to date and that a service can't take others' resources in case of an anomalous event (containerization is your friend here).


Opensource NetFlow generator Cisco routers are able to generate NetFlow flows that can be captured and then analyzed in order to manage what is going on on your network. Unfortunately, I don't have a Cisco router in my toolbox so I'm looking for a opensource/free solution to generate the flows (act as a Cisco router) and to capture them.

I've already found this and this but it doesn't seems to generate flows, only ways to capture them.

Thank you

I think you are looking for softflowd:

Softflowd is flow-based network traffic analyser capable of Cisco NetFlow™ data export. Softflowd semi-statefully tracks traffic flows recorded by listening on a network interface or by reading a packet capture file. These flows may be reported via NetFlow™ to a collecting host or summarised within softflowd itself.
Softflowd can export using NetFlow version 1, 5 or 9 datagrams and it is fully IPv6 capable: it can track and report on IPv6 traffic and flow export datagrams can be sent to an IPv6 host. Any standard NetFlow collector should be able to process the reports from softflowd.


Healthcare company uses keyloggers for security purposes. Is this normal? I just attended a recruitment session for a major healthcare provider in the United States. The presenter, a high-ranking member of one of their IT divisions (not security specifically) mentioned that they use a lot of security software on their client machines, including keyloggers. This person may have misspoken, but there were other members from their various IT departments present, and none of them issued a correction.

This caught me off guard. While I understand that employers, especially in an industry such as healthcare, have an obligation to protect their information from improper disclosure and their machines from abuse, this seems like a step too far.

Is this behavior common in the information security world? A vast majority of the information I found was, as expected, related to the detection, removal, and circumvention of keyloggers. I did find this question (closed as too broad) which has an answer saying that this is uncommon, but since that was only tangentially related and mentioned in passing by one person, I would be much more interested in answers from industry veterans.

It's hard to justify whether it is common or not, as it's unlikely one could come up with a reliable statistics.

What is for sure is that such an approach clearly exists. A security solution applied by a company depends heavily on its threat model, and there is such thing as insider threat (basically, when a malicious employee steals or modifies your data on purpose). Some organizations take it very seriously and choose complicated paths to deal with it, including permanent video recording in all rooms of their back office, screen recording, or, yes, key logging.

As a person who have once seen a surveillance camera in a restroom of a company also related somehow to healthcare by the way, I'm not surprised at all by what you've seen today. Healthcare companies always try to take the privacy issues of their customers very seriously, sometimes even overcaring about those.

Keylogger, which is, yes, usually meant to be a malware, is just a tool here. As with a gun, you can use it to steal something or to protect yourself. Guns don't kill people, people do; and keyloggers don't steal your data. Criminals do.

All that being said, under most circumstances for most of the aspects of the insider issue there are more effective solutions, and there are of course numerous pitfalls of such an approach, ranging from privacy issues (leading finally to low workforce motivation) to assumed inefficiency of such solutions without proper SIEM and UEBA systems, properly integrated with each other. See, when you're collecting all the key strokes from all your workstations, it's a huge amount of data a human can't look through on a regular basis, so you basically need to thoroughly analyse typical user behaviour models with some algorithms to track down what's unusual. This is a task generally rather hard to solve.

Once again, it depends on a threat model whether an organization will accept all the challenges, some of which are outlined above, and go this way or will stick to other options. Of course, if this way is too much for you, you're probably free not to accept a job offer.

(There's a chance by the way the organization you're talking about doesn't really accept those challenges and is just tricking you into thinking you're being watched and recorded, while in fact you're not. You'll probably never know that for sure, unless some amount of binge drinking with members of your information security team will happen eventually.)


Verification Code defeated by fake hotmail addresses Our organization is having problems with hackers/spammers.  In order for them to enter our webpage, we require the user to enter an email address and we send them a verification code to that email address.  At first, they would use a temporary email address (like @sharklasers) to get the code but we've since blocked those domains.  Now we are noticing a lot of nonsensical @hotmail, @outlook addresses like asdfralkaiow@hotmail.com.
Any ideas as to how are the spammers are doing this?  Do they actually have 1000's of legitimate hotmail/outlook/other email addresses that they have access to to get the verification code?  Or do you think there is another way they are getting around this?  The verification code is a 5 character mix of numbers and letter and we've put in limits as to how may incorrect tries they get to enter the code in so I don't "think" they are brute-forcing that part.
Any ideas or suggestions would be greatly appreciated.
Thanks!
EDIT:
******* Additional information to respond to some of the comments/answers *******
I am assuming they are able to get the verification code email and entering in the code correctly because we have logic that restricts the number of chances they get to enter the code.  I won't rule out that there could be a flaw in our verification code process but, as it stands, I can't figure out how they can get in without the verification code so I am assuming they are actually receiving emails at these addresses.
We did implement reCAPTCHA BEFORE we had the validation code email but the spammers were seemingly able to get around that.  So to reduce UX friction, we got rid of the reCAPTCHA and added the verification email instead.  Thinking about it now, though, we did find a problem with our process after implementing the validation code so maybe we should re-visit adding reCAPTCHA back in.
I'm considering them nonsensical because there are hundreds of these email addresses, all with either an outlook.com or hotmail.com domain a day.  Typically, we should only get maybe 30 or 40 logins in total a day.  They look like they exist just to get around our "no duplicate email addresses" validation.  Additional examples:

thaytismtvxuy@hotmail.com
noutopjrvll@hotmail.com
thooshefrmqo@hotmail.com
sheyseauthurfkp@hotmail.com
tathestdx@outlook.com
tandathehfbq@outlook.com
souteegwbt@outlook.com
tisloushafvi@outlook.com
phynyezkxoofv@outlook.com
sesoughurqo@outlook.com

Use CAPTCHA and/or telephone number verification (SMS OTP).
It was perfectly okay to ban known disposable email providers. However, there exist(ed) services that ran on stealthier domains (coming out: I ran one of those).
Free email providers offer email addresses for free, upon simply a registration. They may require a CAPTCHA to prevent automation.
CAPTCHA, which is something you can implement yourself, protects from automated requess, and is decently effective. It blocks automated attacks.
What CAPTCHA does not is to protect from human click farms, where the attacker may hire a large number of poorly paid workers to solve the CAPTCHA, register with a free mail address, and post spam.
By using phone verification, and likely limiting the country of those mobile numbers, you are raising the bar of difficulty to the attacker.
The attacker must get a unique SIM card for every access to your website. Getting a SIM card is not that fast and easy like getting a free email address. Getting a SIM card has a fixed cost (e.g. when I change provider I always pay a non-refundable-in-credit cost around 5€ for the hardware, the card itself) and in many countries it requires proof of ID, which raises a yellow flag in a phone company if someone activates a stock of 1000 SIM cards.
Please note that this won't completely stop spammers, but will slow them down. Probably a lot, so that you will simply notice them no more.
Your mileage may vary
Please remember that antispam techniques are meant to slow down large attackers, not completely stop them
I suggest to take a look at this video that shows what a click farm is. An attacker with enough human resources can still get a decent number of SIM cards, have humans solve CAPTCHAs, register for emails and send spam.
There are similar videos. A click farm is an organization originally made for the purpose of boosting social media scores (likes, follows and engagement).
Beware!


Repercussions of hacked router? I am staying in Thailand right now on a "long holiday" to do some work on my laptop.

A few weeks I noticed that at the condo where I am staying, sometimes I am redirected to ad sites. I researched it and learned there may be some problem with the wireless router's security (the model, TD-W8961ND, has a known vulnerability). I can find the router at  192.168.1.1 but no passwords work. I believe the attackers may have changed the password. Just yesterday, the attacks got severe and most websites would redirect to a fake site to "upgrade flash player" (malware file).

I tried to get the router replaced but when it came back from the ISP, it still has the same problem. So it looks like the router is still configured to redirect to malicious addresses.

My questions are:

1) What is the likelihood that financial information conducted over SSL could have been affected during this breach? Passwords? I normally don't fall for these traps but since I was using a compromised router for 2 months, it's possible they got me somehow.

2) I am now using a secure OpenVPN connection and no longer experiencing any problems from my router because my requests are all going to the VPN server first. If I stay connected via VPN, am I still vulnerable to problems exposed to me by this router? (Let's assume there's no way I can actually fix the problem).

3) Or, does anybody know if there's a way to force-reset the router back to admin/admin so I can log in and look at the security settings and patch the vulnerability?

Regards,

Grey

1) As long as your browser has shown a green (or at least not red and with a warning message) https in the address bar then you've successfully authenticated to the other end without compromise. It's highly unlikely for the attacker to be able to man-in-the-middle the SSL connection without the private keys of the host server (e.g. your bank) to sign the ssl certificates that the https host has. If he tried to sign certificates, the browser would detect his falsely signed ones.

2) As for VPN, it depends. If you do it over SSH, make sure the presented fingerprint is in fact that of the host you are connecting to. The fingerprint might be cached by your computer already, so if your VPN connection starts automatically, the chances are very high that there is no compromise otherwise the VPN software would throw some alert message at you saying that the fingerprint has changed (indicating a possible man-in-the-middle).

Of course, if you do anything over plain old HTTP, forget about all security.

3) I'm sure there's a way. Just google the make and model of the router.


Can I repair a cut-through credit card? On many cards there's the instruction to, if found, cut it in two pieces and mail them to some address. I'm wondering a bit about the security of this and if I could recover some data.

It's not necessarily a perfect cut through the exact middle, since people usually aren't that careful.

First off, if I cut the magnet stripe in half, can I repair it, or get the data off of it to make a copy?

Secondly, if I cut the chip in half, how likely is it that it's too broken to recover data from?

Thirdly, contactless payments. Same question.

I'm quite sure you will be able to recover  "some data" from the magnet stripe - likely even all the data that's on there. However, you won't be able to withdraw any cash with a copy of that stripe because nowadays use the information on the chip, which is much safer as it is much harder - close to impossible, I would guess - to copy that. The only thing you could hope for is a store with an old terminal, but then you have to give your copy of the card to a person...

As for the chip, if you don't have the means of an intelligence agency or something like that, you won't be able to repair it. (The chip is not just a "data store" that is to be read but a device that can answer cryptographic challenges.) Same thing should apply for contactless payment.

Thanks for the comment: I'm referring to the situation in the European Union, namely EC-cards, which are most common over here.


Chrome: Your connection is private but someone might be able to change the look of the page I happened to come across this (govt) website which should be HTTPS-secured, but Chrome does not show the green lock. Instead it shows this:

What does it mean? How can attackers leverage this vulnerability?

The page that your browser displays on the screen might consist of many elements: the HTML code, CSS, images, etc. Also some of the content might be provided, enhanced, or altered by (legitimate) scripts downloaded from the site. These elements might be included from the same server or from other servers.

For Chrome to display the "Your connection to this site is private" message, for each element of the page:

an encrypted HTTPS connection must be established
site certificate (identity) must be valid
non-deprecated protocols and algorithms must be used

If one or more of the elements is included through a non-encrypted HTTP link, then:

if it is a script, Chrome will display a message:

  Your connection to this site is not private because the site loaded an insecure script.

In such case there is a possibility that the script was replaced with a malicious one. Any data you receive from the site or sent to the site can be intercepted and changed.
if it is (only) a passive content (like an image), Chrome will display a message:

  Your connection to this site is private but someone on the network might be able to change the look of the page.

In such case no one would be able to sniff on your data or read the information that the site provided. However by altering the look of the page you might be tricked into performing an action you did not originally intend to, for example resetting your password. Although the password change itself would be secure and legitimate, it might benefit the attacker.

Also, this message is not 100% accurate. Depending on the actual passive content being included, a passive attacker can deduce what actions did you take on the encrypted site. Unlike with HTTPS, with HTTP the full URL would be visible, so if a certain page loaded a unique set of icons, an attacker would be able to tell you reached that page.


Allow copy-paste into MS Remote Desktop, but not copy from there? I have a Microsoft Remote Desktop connecting to a server.

Is it possible to enable copy-pasting from my local computer into the remote windows, but disable it the other way round?

(this way it would be harder to export data from the remote machine)

Like @paj28 indicated it's not possible to limit the Clipboard functionality one way.

You would need to disable it completely.


Self-signed CA and combining wildcard and SAN certificates I have created my own Certificate Authority and installed the certificate on a few computers.

Now I have generated a server certificate with common name *.mydomain.com and Subject Alternative Name (SAN) DNS mydomain.com to match all first level subdomains and the root domain. I signed the server certificate with the CA.

The browsers Firefox and Safari accept the SAN mydomain.com but fail verifying the wildcard domain *.mydomain.com. Error message:

Certificate belongs to a different site...

Can I not combine wildcard and SAN or do I have to put the wildcard in the SAN? Or both in the SAN?

It is not a matter of wildcards. The behaviour you observe is due to the following: if there is a Subject Alt Name extension in the certificate, then the Common Name part of the DN is simply ignored. Said otherwise, the server names in the certificate should always be in a Subject Alt Name extension; the Common Name part of the subject DN is used as a fallback only if the Subject Alt Name extension is altogether missing (precisely, if there is no SAN, or if there is a SAN which contains no dNSName element at all). See RFC 2818, section 3.1:

If a subjectAltName extension of type dNSName is present, that MUST
be used as the identity. Otherwise, the (most specific) Common Name
field in the Subject field of the certificate MUST be used. Although
the use of the Common Name is existing practice, it is deprecated and
Certification Authorities are encouraged to use the dNSName instead.

Therefore, in your case, you should put both mydomain.com and *.mydomain.com as dNSName elements in the SAN extension (the SAN extension can contain many DNS names). Whether names are wildcard or not does not matter at this level. As an illustration, have a look at the certificate used by Google (connect on https://www.google.com, then ask your browser to display the "certificate details"): this certificate currently features a SAN extension with no less than 44 DNS names, 34 of which being wildcard names.


Why are short-lived certificates so rare? Let's encrypt recently left beta and limits the maximal life-time of certificates to 90 days and recommends 60 days.

Now whenever I start talking about the issues of certificate revocation (e.g. OCSP soft-fails) I get to hear: "short lived certificates are probably the best solution".

So my question is:
Why are short-lived certificates a relatively recent trend and have not been deployed in the three decades before by the big CAs?

Note that in theory it's in the CAs best interest to deploy this, as they could actually save the heavily loaded OCSP servers and the earn enough money through certificates to develop a robust automatic certificate renewal tool.

It would be a huge operational cost in environments that don't have automated certificate management in place, which, in reality is the vast majority of the operational environments in the world today.  In fact, in most environment little to nothing is automated.  We've just started seeing people dip their toes in those waters in the past few years, and most mainstream organizations only in the past year or two.

So, when making a modification to server (like replacement a certificate) requires a purchase order, a manual deployment by a server admin, and a 4-6 week change management process, and you multiply that by, say 10,000 times for a moderately large-ish organization, short-lived certs go from being a challenge to an impossibility.

Certainly there are organizations (like Google, for instance) who have this nailed, at least on their public properties (I don't know if their enterprise systems get the same attention) and it will start to invade the mainstream with tools like Let's Encrypt's ACME client.   But that hasn't existed for long, and there was nothing else out there before that made this easy for a organization that isn't sophisticated to implement.  Add that to the fact that fake or stolen certificated haven't been a massively widespread or expensive problem organizations have needed to struggle with, and there wasn't really any incentive to invest in a solution.   The real answer is to make short-lived certs cheaper and easier to manage than long-lived certs. That is when they'll take off, and why Let's Encrypt holds such great promise in this area.


Possible to use *only* U2F authentication? Using a U2F USB authentication key to login to services such as Google seems a good idea. However, these services often allow you to register a backup two-factor-authentication (2FA) method, which you can use in the event that you lose your U2F physical device.

The fact that you can just use a 'backup method' to login to these services seems to defeat the point of having the U2F key in the first place. If security is only as strong as the weakest link, then a hacker with password access to an account can just bypass the U2F device by claiming that the key went missing, using (for example) SMS.

On the other hand, people may not want to risk all their web account access to a single USB device. If it's attached to their keys, there's every chance it could get lost, left out in the rain, etc etc. Ideally, it would be possible to purchase two U2F devices that are registered with the identical 'secret'. By not allowing any other 2FA method, then in the event that the U2F device went missing, I would have a backup securely stored at home.

Question: Is it possible to duplicate U2F devices and set online services (such as Google) to only allow U2F, with no other backup method? Obviously if a user were to buy two U2F devices and they were to both go missing, then the user would be irreversibly locked out of their online accounts, but this would be a risk that the user would knowingly sign up to. I really can't see the point in switching to U2F devices unless this is an option.

If the service you are using support multiple different U2F devices you may add more than one to the service. In the Google case I belive they support more than one device linked. To dissable the backup security codes you may simply use them all.

You can not duplicate your U2F device, but there may be manufacturers selling pairs. By design the U2F device should be write-only i.e. only returning replies to challanges, not the secret stored. Allowing the secret to be read (in order to create a duplicate after creation) may pose a security risk since someone obtaining your U2F device may create a duplicate without your knowledge.


Consider a "zero-knowledge" file host such as mega.co.nz. How can one prevent users to upload unencrypted content? I am wondering how could a zero-knowledge host such as mega.co.nz prevent users to just upload files in clear, and, for example, to discredit the site by uploading a large quantity of illegal material and then telling the authorities.

Ideally, the server should refuse unencrypted uploads. However, what's a definition of "unencrypted" that a computer may understand? I guess there's none.
It could be that by pure chance, a JPG picture of a giraffe is actually the cyphertext of some other encrypted document. This is just very unlikely. And a computer can not really tell a picture of a giraffe from a file that has jpg headers and random noise. One could reject files based on headers (e.g., using the unix "file" utility) but that seems a bit unreliable, and would sometimes reject legitimate uploads.

It can't.

There are heuristics to tell whether a file is encrypted, but they're unreliable, and they're useless anyway.

An encrypted file is uncompressible because the encryption hides all the patterns. Except when it's not: if you encode an encrypted file in hexadecimal (with two bytes to encode each original byte), it takes twice as much room, so you can compress the hexadecimal version by 50%, but the hexadecimal version isn't less encrypted. Conversely, if a file is uncompressible, if may be encrypted, or it may simply be already compressed with an algorithm that's at least as good as what you have. So in fact an encrypted file may or may not be uncompressible, and a plaintext file may or may not be uncompressible,

An encrypted file contains no recognizable patterns. Except that of course it can contain, for example, a header indicating the type of encryption. Or it can recognizably contain only hexadecimal digits. So in fact an encrypted file may or may not contain recognizable patterns, and a plaintext file may or may not contain recognizable patterns.

An encrypted file may very well be a JPG picture of a giraffe, with information encoded in (say) the low-order bits of each pixel. See steganography.

Even if a file is encrypted, you can't tell, say, an AES-CBC-encrypted file from an AES-CBC-encrypted file with the key prepended. Except by trying to use the first 16 bytes as the key — and then you'd need to try out all the other ways the key may have been put in there.

Let's say that the file really is encrypted and cannot be deciphered with only the uploaded material. The creator of the encrypted file could still publish the key elsewhere.


What is the best way to approach and generate apparmor profiles? I'm thinking to start making apparmor profiles for my server, but before I start, I want to make sure that I'm doing in a right way.

So, I'm thinking to begin with apache2 profiling. Right now I'm running couple of websites and some of non-default apache modules like modsecurity.

After checking aa-status, there are already some of default profiles:

   /usr/sbin/clamd
   /usr/sbin/mysqld
   /usr/sbin/named
   /usr/sbin/tcpdump

So if I fire aa-genprof apache2, it will return:

Profiling: /usr/sbin/apache2

[(S)can system log for AppArmor events] / (F)inish

What should I do after that, restart apache, browse on my sites in order to catch apache movement?

apparmor is to protect services... for example if "something" tries to change configuration files of a protected service...  Look at this.

To test it you must try to change any service... Not sure about how to test it with apache, but if the point is test if apparmor is working, you can doit with another service I know how it works:

If you install isc-dhcp-server package, by default I think ubuntu is protecting this service... then you can try to launch the dhcpd command setting a config file directly in the command (something like dhcpd -d -cf <yourPathToConfigFile> <yourInterface>)... you will see it doesn't work, even if your configuration file is good. It only works if the file is in /etc/dhcpd/.


Can malware infect more than one operating system? Is is possible for malware to be written in a low-level language such as C or C++
and do the following:

Infect a single operating systems(such as Windows)
Detect other machines on the same network
Determine other machines operating systems
If the operating system is the same(Windows) attempt similiar attack
If the operating system is different(OSX or Linux) use quine or download a small attack module to attack the different operating system

TL;DR: Can a C or C++ virus attack multiple operating systems?

(9/8/2016) UPDATE:

Here is recent article of what I am talking about: http://thehackernews.com/2016/09/cross-platform-malware.html

Short answer: certainly.  Remember that once your system is compromised (step 1 in your question), and attacker can perform downloads and run ARBITRARY code.  A common approach is "fingerprint and drop", wherein the malware determines the characteristics of your system, and downloads appropriate payloads to execute the attack.

An example of a worm which runs on Windows but is designed to attack another system would be Stuxnet.

An example of malware which fingerprints and drops would be any exploit kit (for example, Angler) that uses drive by downloads.


How to debug/reverse engineer java applets? I need to analyze a java application (a .jar file) for a war game. I know java can be decompiled, but the coder apparently did a lot of obfuscation to prevent the reverse engineers from understanding how his/her application works. So I thought it would be better if I used a debugger. Would you guys recommend me a debugger like ollydbg but for debugging java applets?

jdb/jdebugtool seem to fit your requirements.

Though a decompile (http://java.decompiler.free.fr/), pulling into your favourite IDE and then stepping through may be a neater approach? That way you can isolate methods and play with them individually. If you have a behaviour you want performed, that you can identify, such as incrementing a specific counter, you can cut through a lot of obfuscation by stepping through from something else (such as click button 'A') that you know should have that ultimate effect.


Implementing Secure Remote Password: Constructing the verifier The SRP protocol as described in RFC 2945 generates the password verifier:

x = SHA(<salt> | SHA(<username> | ":" | <raw password>))`
v = g^x % N

I have three questions: why use SHA twice, why involve the username and why add a separator?  Do these add any practical security over x = SHA(<salt> | <raw password>)?

SHA-1 is not an ideal hash function (actually, neither are the SHA-2 functions). The double hash invocation hides a few of the internal shortcomings of SHA-1. This is similar to HMAC, which also uses a double hash invocation for pretty much the same reasons. In more details, we want the function which maps the username-and-password to x (function selected by the salt among a family of functions) to behave like a random oracle, and the normal security properties of hash functions (collision resistance, preimage resistance) are not enough to guarantee such behavior.

The username is involved so as to make security proofs easier: it allows the security analysis to concentrate on a single user, without having to account for what happens when a given server accepts several users, each with his own password. The separator participates to the same goal: otherwise, "john" with the password "ny67dtzo" and "johnny" with the password "67dtzo" would live in the same world, security wise.


How can I test my SSO connection without having access to the Identity Provider? I'm trying to set up an SSO connection using Auth0. My app is set up as the Service Provider (SP), and it needs to work with PingFederate as the Identity Provider (IdP).

I don't have access to an account with the IdP, but I want to test that I've got everything on my connection set up correctly - how can I do that without installing and setting up a PingFederate server?

In the end I used the service SSO Circle which is a freemium public IdP service that you can use to test your connection. It provides metadata, certificates, the whole shebang.

There seems to be a concurrent session limit for the free account and you don't get any error logging/deebugging tools (and the interface is a bit naff) but its certainly better than not having an IdP to test with!


Do TLS standards require the server-side preference to always be used when negotiating ciphers to use? Someone told me the other day that the TLS standards require the server-side to always have the authority to decide which mutual cipher to use when negotiating with a remote client.

This makes sense, but gets me to wondering how long this has been the case and why there are options like: +SSL_OP_CIPHER_SERVER_PREFERENCE in openssl for CTX options: https://www.openssl.org/docs/man1.0.2/ssl/SSL_CTX_set_options.html

  SSL_OP_CIPHER_SERVER_PREFERENCE

  When choosing a cipher, use the server's preferences instead of the client preferences. When not set, the SSL server will always
  follow the clients preferences. When set, the SSLv3/TLSv1 server will
  choose following its own preferences. Because of the different
  protocol, for SSLv2 the server will send its list of preferences to
  the client and the client chooses.

This doesn't make sense...

Within TLS the client sends a list of supported ciphers in the order of their preference by the client. The server has its own lists of ciphers it is willing to support. The server is free to choose any of the ciphers the client offers and which are also supported on the server side. How this choice is done is not specified. To keep the choice simple the OpenSSL API lets the server application choose between two strategies: use the client's preference of ciphers or use the server's preference. There are arguments for both of these strategies:

use the client's preference:
The client might show a preference for ciphers which are strong enough but need low computing resources on the client. For example clients having native instructions for AES will probably prefer some AES based cipher. Clients without such instructions (like low end ARM processors) might prefer ChaCha20 instead since this algorithm needs much fewer resources in this case.
use the server's preference:
Encryption is not really cheap and the server might thus prefer ciphers which needs the fewest resources on the server (but which are still strong) in order to serve many clients in parallel. Thus even if the client would prefer ChaCha20 to save resources on his site the server might choose an AES based cipher since it is much cheaper to do on the server if the server has hardware support for AES (most do).


RSA Key Pair generation with Javascript I need to generate a RSA key pair with Javascript. This key pair will be used for encrypting a one time blob of data (20-100kb), then discarded. This data can be reduced to a couple of hundred kb or less if I only encrypt data that needs to be secure and not other resources such as image files for the application.

Should I write my own implementation or are there any libraries that I can trust to be both stable and secure?

You could take a look at the GWT Crypto package.  Its a port of some of the BouncyCastle stuff into GWT, so you should be able to take the compiled output and massage it a bit so you can call it from your current Javascript.  It currently supports RSA keypair generation and encryption/decryption, as well as AES and DES.  I think that's about it though.

I personally have not used this library, but since it was ported from BC it should be safer than writing your own implementation.  That said, I dont know where they sourced their SecureRandom implementation from.  You may need to look to see if its actually a cryptographically secure implementation or not.  I took a quick look and they are just doing something with SHA and the seed bytes, but I dont know if that qualifies or not.

One last thing.  I have found using RSA to encrypt large amounts of data to be quite slow.  Perhaps you may want to use a hybrid solution of some sort where you encrypt an AES256 key using the RSA keypair and then use AES to encrypt the data?  Could be faster...


What's the limit on the size of the data that public-key cryptos can handle? Someone mentioned here that asymmetric encryption might not be appropriate for bulk data and gave an example of RSA with 100 bytes. Of course, I understand that it was a rough example. But it made me curious - how much size of data can various public-key crypto handle in general and how much can a JavaScript library like OpenPGP.js handle in particular. In the latter case, does the browser environment add more limitations?

Added:
Is there any reputed online resource that has a discussion / comparison of the various Public-key cryptos with regards to the limits on size of data?

In order to answer your question, your misconceptions must be corrected first. In most cases, padding in RSA adds 11 bytes to the message. So, using a 1024-bit key, you'll have 117 bytes available for the message. That's why RSA isn't usually used to encrypt messages, it's mostly used to encrypt symmetric keys used to encrypt messages. This is called a hybrid cryptosystem.

For example, in PGP, a symmetric key (sK) is created, the message is encrypted with sK, then sK is encrypted with the public key, and both (the encrypted message and the encrypted sK) are sent to the recipient. The recipient will use his private key to decrypt sK and use that to decrypt the message.

Technically speaking, there's no limit on the size of the message PGP (and, consequently, OpenPGP.js) can handle. Limitations might come from the amount of available memory, the amount of memory utilizable by the browser, etc.