Data security while MacBook is on lock screen I've recently sent my MacBook (running on Catalina) to repair by a licensed Apple service provider. The whole thing was simple (replacing one key cap) and took about 5 minutes or so. But I forgot to shut down the MacBook and only put it on lock screen. I have FileVault enabled.

Is it possible for my data to be breached in that scenario? My understanding is that FileVault only protects your data by requiring you to enter your login password when you start up the drive. It sounds like once you have logged into the computer (even if it is now on lock screen), the data is decrypted and vulnerable to unauthorized access?

Thanks in advance!

I don't have detailed information on FileVault, but all FDE (Full Disk Encryption) schemes perform best when computer is cold, namely shut down completely.

FileVault suffers the same weaknesses as other FDE schemes such as MS BitLocker and LUKS: while they secret key is stored on RAM an attacker with appropriate tooling may reset the CPU and dump RAM contents before the content vanishes. This is no simple thing to do, especially when hardware is compact enough. But is very well documented as a weakness of FDE.

Please note: data is always stored encrypted on disk. The data is not decrypted after boot. FDE decrypts only the data it needs every time, and decrypts that into RAM. Swapping a spinning disk has no effect with regards to security.

You said tech took 5 minutes to replace the key. I don't have record of how much time it takes to perform the hot boot attack, but data being volatile in RAM is matter of time.

I would be very confident that either:

The tech did just his job to replace the hardware keyboard honestly
In the back of the tech shop there were two techs paid by some government agency: one actually replaced you keyboard, the other was working to spoof national-security secrets (i.e. I am currently responding to a diplomat, a prosecuted national hero, a wanted terrorist or a mafia...) within 5 minutes of your arrival. They knew you were coming to that shop, they broke your keyboard on purpose to have you there, that day, that time. Mr. Bond would be a little surprised.

In short: I am confident your data is safe. Bomb me if I am wrong


Did Wireshark capture an update of Adobe Acrobat Reader over an unencrypted connection? My home router is an AVM FritzBox and it's able to log all incoming and outgoing traffic in a file format readable by Wireshark. Some days ago I started capturing all traffic for about an hour to get an understanding of what kind of traffic is leaving and entering my home network and to get more familiar with Wireshark.
Most of the traffic is encrypted with TLS and I am only able to see the domain in the Server Name Indication (SNI) field. I was also intersted in figuring out which traffic is unencrypted.
To only see incoming unencrypted traffic I enter the filter http.response. There is lots of traffic where the protocol column says OCSP. To exclude this traffic I update my filter to (http.response) && !(ocsp).
Now multiple packets are shown, e.g. this one:
Info: HTTP/1.1 206 Partial Content  (application/x-msi)
Response for URI: http://ardownload.adobe.com/pub/adobe/reader/win/AcrobatDC/2001320074/AcroRdrDCUpd2001320074.msi

Full copy of this packet:
Frame 24636: 1462 bytes on wire (11696 bits), 1462 bytes captured (11696 bits)
Raw packet data
Internet Protocol Version 4, Src: a23-48-202-107.deploy.static.akamaitechnologies.com (23.48.202.107), Dst: redacted.fritz.box (192.168.redacted.redacted)
    0100 .... = Version: 4
    .... 0101 = Header Length: 20 bytes (5)
    Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
    Total Length: 1462
    Identification: 0xebac (60332)
    Flags: 0x40, Don't fragment
    Fragment Offset: 0
    Time to Live: 61
    Protocol: TCP (6)
    Header Checksum: 0x1415 [validation disabled]
    [Header checksum status: Unverified]
    Source Address: a23-48-202-107.deploy.static.akamaitechnologies.com (23.48.202.107)
    Destination Address: redacted.fritz.box (192.168.redacted.redacted)
    [Source GeoIP: US]
Transmission Control Protocol, Src Port: http (80), Dst Port: 50146 (50146), Seq: 256, Ack: 495, Len: 1422
    Source Port: http (80)
    Destination Port: 50146 (50146)
    [Stream index: 112]
    [TCP Segment Len: 1422]
    Sequence Number: 256    (relative sequence number)
    Sequence Number (raw): 4050263504
    [Next Sequence Number: 1678    (relative sequence number)]
    Acknowledgment Number: 495    (relative ack number)
    Acknowledgment number (raw): 2051456861
    0101 .... = Header Length: 20 bytes (5)
    Flags: 0x018 (PSH, ACK)
    Window: 245
    [Calculated window size: 31360]
    [Window size scaling factor: 128]
    Checksum: 0xf913 [unverified]
    [Checksum Status: Unverified]
    Urgent Pointer: 0
    [SEQ/ACK analysis]
    [Timestamps]
    TCP payload (1422 bytes)
Hypertext Transfer Protocol
    HTTP/1.1 206 Partial Content\r\n
    Server: Apache\r\n
    Last-Modified: Wed, 09 Dec 2020 11:36:16 GMT\r\n
    ETag: "7856800-5b6067797a9f1"\r\n
    Accept-Ranges: bytes\r\n
    Content-Type: application/x-msi\r\n
    Date: Tue, 22 Dec 2020 08:01:54 GMT\r\n
    Content-Range: bytes 0-1119/126183424\r\n
    Content-Length: 1120\r\n
    Connection: keep-alive\r\n
    \r\n
    [HTTP response 2/37]
    [Time since request: 0.016112000 seconds]
    [Prev request in frame: 24632]
    [Prev response in frame: 24634]
    [Request in frame: 24635]
    [Next request in frame: 25074]
    [Next response in frame: 25085]
    [Request URI: http://ardownload.adobe.com/pub/adobe/reader/win/AcrobatDC/2001320074/AcroRdrDCUpd2001320074.msi]
    File Data: 1120 bytes
Media Type
    Media type: application/x-msi (1120 bytes)

Am I correct to assume that this captured packet is an update of Adobe Acrobat Reader over an unencrypted connection?
If yes, could this be used in a man-in-the-middle-attack to insert malicious code into the update or replace it completely?

I see it's using HTTP instead of HTTPS so yes, it is vulnerable to MITM. However, the software that is downloading the file may be validating it, for example using a checksum or verifying a digital signature.


Protecting a website from being kidnapped I have a MediaWiki website in Hebrew;
As common with MediaWiki websites, it has lots of content and rebuilding it in case of a disaster isn't feasible.
I chose to give that website a Global TLD (a non Israeli X.il TLD) because:

Currently, the Israeli Internet association doesn't allow Israeli domain registrars to suffice domain holder details protection; everything must be exposed to anyone, even if it is against the domain holder's freedom and safety
As I don't have an Israeli phone number, some Israeli domain registrars would not support non-Israeli phone numbers and thus, various domain management system software bugs are likely to occur

My problem
Although I have quite a strong email password (>12 lowercase-uppercase-numbers password) which isn't stored on my computer system but rather solely on my human memory;
I still fear a kidnapping of the website by hijacking of my email password.
If someone hijacked my NameCheap account and/or my SiteGround account and/or my MediaWiki website but not my email account, than I guess I could log in and change everything back to normal (likely by using a backup), but as I currently don't clear web browser passwords from the main browser I work with (and would prefer to keep handling this way), I do fear an hijacking of my email account (say, by a MITM attack) and then of all the rest, till complete kidnapping of my website.
Possible obstacles in solving the problem

I only hold Israeli citizenship but not Israeli residency and anyway don't have an Israeli residence address (and currently prefer not to give that of a relative)
Neither NameCheap (domain registrar) nor SiteGround (hosting provider) allow me to upload any image of my Israeli passport and/or Israeli ID card (or of myself) which will be automatically copied and principally permanent in their servers.
Writing my name and putting an image in which my face could be seen in my website is something I want to avoid and would probably be not helpful because an hijacker could delete it (it is hard to delete data from the database of MediaWiki and could cause crashes, but still possible).

My question
How to protect a website from being kidnapped as described above?

If you are afraid an attacker might login to one of your accounts, it is best to ensure that all accounts have strong and unique passwords (e.g by using a password manager) and have 2 factor authentication enabled.
This way, if the attacker gets a hold of your password, he can not log in as he does not have the 2FA device.
As for your website, make sure you have proper working backups and test these periodically. Also ensure the backups are at safe locations which you control and can not be accessed by an attacker if he has hacked into your site/host/email.
Apart from protecting your accounts, also make sure the systems hosting your website (and the platform itself) are up-to-date.


Can my college Wi-Fi admin obtain the serial number/IMEI of my device? I am using my own device on my college's Wi-Fi. I've heard that many pieces of information about my device such as my OS version is sent through a browser such as Google Chrome. But how can he obtain my serial number if he wants?

The Wi-Fi admin can only get your MAC Address of your device.

This is needed for you when connecting to Wi-Fi and to get a IP Address.
But MAC addresses can be spoofed.

He cannot get the IMEI number, unless he make you install some software or App on you device.

He also gets your OS version and browser details is via the request Headers of browsers.

Here is a sample. You can see the User-Agent contains the info of your OS.
In my case Windows NT 6.1 and browser information Firefox/38.0.

POST /posts/validate-body HTTP/1.1
Host: security.stackexchange.com
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Firefox/38.0
Accept: */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
DNT: 1
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
X-Requested-With: XMLHttpRequest
Referer: http://security.stackexchange.com/questions/135142/can-my-college-wi-fi-admin-obtain-the-serial-number-imei-of-my-device
Content-Length: 177

You can spoof this Information as well using various methods.

Edit:

The Above HTTP request headers can be read if you are browsing  plaintext protocols like  HTTP.

When a DHCP request is made the Hostname is sent as well.


Tiger team versus red team? What's the difference between a tiger team and a red team? Are there any other "color" teams out there (relevant to IT security)?

I have only heard of two types of teams:

Blue team - The defenders of a network
Red team - Attackers of a network
Tiger team - Same as red team, however is a older term of the attacking/opposition side of an engagement
White team - The team that establishes the rules of engagement and are usually the employees of the organization. The white team does not conduct any testing.

CISSP study guide has the following explanation of the different teams:

  White team  A neutral team of employees acting as observers, referees, and judges between > a red team of mock attackers (offenders) and a blue team of actual defenders of their
  enterprise’s use of information systems. The white team establishes rules of engagement
  (ROE) and performance metrics for security tests. The white team is also responsible for
  deriving lessons-learned, conducting the post engagement assessment, and communicating
  results to management. Occasionally, the white team also performs incident response
  activities and addresses bot attacks on an emergency basis.


Mac OS hacked via Bluetooth? I was working from Starbucks today on my Macbook Air running OS X 10.11.5, and a strange thing happened.

I was in Chrome and browsing the web, when a Bluetooth connection request popped up from an unknown device. I rejected the connection, and continued on, assuming someone had simply accidentally requested to pair with the wrong device. A few minutes later, another pairing request from the same device, I rejected it again, and then turned off Bluetooth. (I noticed that there were two trusted devices listed - an apple keyboard and trackpad.)

I was working in Chrome and had several windows open, and within a few minutes, it had completely bogged down and was beginning to lock up (somewhat unusual, but not entirely unprecedented since it'll occasionally max out on RAM with lots of chrome tabs open, but usually it's a far larger number).

I decided to reboot, so I closed out everything and hit restart. During reboot, it briefly showed some error messages and text over an image background. Unfortunately, I wasn't able to read much of the text before it moved on, but it mentioned the registry and listed out lots of memory locations like 0x01515125125 etc. I've never had any issues with it or seen the screen before. It did a quick cycle through and then presented me with the normal login screen.

It seemed very fishy to me at this point, so I loaded into the guest account. I was googling around to see if it's even possible to get hacked via an open Bluetooth connection, and then a box popped up saying 'Safari wants to use your "login" keychain', which I canceled (never seen before, but then again - I don't use safari), and continued browsing. A few minutes later it popped up again and I was like "f it I'm out" and left. Booted my laptop on the way home and logged into my admin account and disabled Wi-Fi.

Am I being super paranoid here? Is this even possible to get a keylogger or malware like that? How could I verify?

Piquing my interest, I wanted to do some research and found that these types of cases are relatively common. In cases like this, if your Security & Privacy settings are still set to default and bluetooth is regularly used in conjunction with the Public folder, then yes, there's the potential that someone could gain access. But, only to that Public folder.

Alternatively, it bears mentioning, that bluetooth devices when discoverable will search for all the other bluetooth devices in range, which is about 20 - 30 feet. This doesn't necessarily means that they're connected, but that the Mac can see the device for pairing.

There's an interesting paper that details tracking anonymized bluetooth devices, but this is in-keeping with an adversarial mindset and that the target is being actively monitored and tracked. They examined W10 devices as well as MacOS and iOS devices using the below criteria:

  We passively record advertising events, while Bluetooth in macOS / iOS
  is enabled. Additionally, the Airdrop sharing feature is launched on
  the respective devices, and the resulting advertising events are
  recorded. We measure data generated by various up-to-date iPhones
  Tracking Anonymized Bluetooth Devices58(iPhone 5s, iPhone 8, iPhone X,
  running iOS 11),two iPads (iPad, iPad Pro running iOS 12), and two
  Macs (iMac A1419 and Macbook Pro A1502 running macOS 10.13)

From a MITM perspective, there was a bluetooth security flaw, which CERT issued a security warning for in 2018 that details "Bluetooth firmware or operating system software drivers may not sufficiently validate elliptic curve parameters used to generate public keys during a Diffie-Hellman key exchange, which may allow a remote attacker to obtain the encryption key used by the device."

The impact of which was, "An unauthenticated, remote attacker within range may be able to utilize a man-in-the-middle network position to determine the cryptographic keys used by the device. The attacker can then intercept and decrypt and/or forge and inject device messages."

Nevertheless, this was patched fairly quickly and, should a user be up-to-date, would have little reason to be concerned. However, there's always means to harden security on a MacOS device and, while it may defeat the purpose of some of the convenient, streamlined interoperability of Apple devices (e.g Handoff, Airdrop, etc.), it decreases the potential of a malicious attack on the computer.

Regardless of the Apple Security Platform narrative, it bears keeping in mind that there necessitates a reasonably security-oriented mindset when it comes to having a machine that connects to the internet or is capable of connecting to any other device. While it's arguably not feasible, the most secure PC is the one that never touches the internet. In this case though, there isn't anything to really worry about.


Grep Commands with User Input I'm curious if there is a way to make user input safe for grep commands. I have a search box that should allow an end user to search a directory recursively for files containing a string.
I could accomplish this solely with PHP but grep should be faster and is therefore preferable so long as it can be made safe.
I will not know the contents of the search string but it will likely have a limit of n characters.

You can prevent command injection which should be done by giving the regex to grep via stdin rather than relying on escapeshellarg() as it has some tricky edge cases like argument injection. You will still be vulnerable to regular expression abuse such as denial of service and can also disclose content of unintended files. Try running grep '' /etc/passwd.
Most search functions work by analysing files/content and building a data store which can be queried. Using grep is a dirty work around and has some.big problems.


Gmail password on another device. I sold my android phone. I had account saved for google apps. When I change my password of gmail account,  can it be possible to log in from previous phone by buyer?

Changing your password should be all you need to do.

In addition to this (if it were me), I'd turn on two-factor authentication.  This will require a code (sent through SMS or from an authenticator app on your new phone) to be typed in, in addition to your password and will ensure only you are able to log on to your account.

That being said, you can also take extra precautions and go to the Google Account Security page and make sure that only the devices and computers and apps that you want to have access to your account actually do:  https://myaccount.google.com/intro/security

Another link for reference detailing the de-authorization of other app passwords and devices that are potentially using your account:  https://productforums.google.com/forum/#!topic/drive/tHVFkE1nsZ4


HIPAA compliant blob storage architecture There is a task to design a system to store sensitive data securely (should be HIPAA compliant in the future). It's just a draft - this will not be used in production in a foreseeable future. I have a prototype inspired by TrueVault and want to know if there is some semantic security lacks or violations of security concepts in it.

So the system consists of 4 subsystems:

Encryptor/Decryptor (Cryptor) is responsible for random key/iv generation, encrypting and decrypting binary data with AES-256-GCM algorithm (OpenSSL implementation). This server performs only in-memory operations and stores the result inside 3 other subsystems and is connected with them via IPSEC or SSL VPN. Three other subsystems have no direct connection between each other. External client uses only encryptor/decryptor public interface and is not directly connected to other subsystems.

Public interface:

dump(client_binary_data) -> external_uuid
load(external_uuid) -> client_binary_data

DataStore stores [data_store_uuid, encrypted_data, auth_tag] triplet.

dump(encrypted_data, auth_tag) -> data_store_uuid
load(data_store_uuid) -> [encrypted_data, auth_tag]

KeyStore stores [key_store_uuid, key, iv] triplet.

dump(key, iv) -> key_store_uuid
load(key_store_uuid) -> [key, iv]

MapsStore stores map between DataStore triplet, KeyStore triplet and external_uuid: [external_uuid, data_store_uuid, key_store_uuid].

dump(external_uuid, data_store_uuid, key_store_uuid)
load(external_uuid) -> [data_store_uuid, key_store_uuid]

Workflow:

Cryptor.dump(binary)

generate external_uuid
generate random key
generate random iv
use external_uuid as AAD for AES-256-GCM
encrypt client_binary_data -> encrypted_data
derive auth_tag
KeyStore.dump(key, iv) -> key_store_uuid
DataStore.dump(encrypted_data, auth_tag) -> data_store_uuid
MapStore.dump(external_uuid, data_store_uuid, key_store_uuid)
Return external_uuid to the client

Cryptor.load(external_uuid)

MapStore.load(external_uuid) -> [data_store_uuid, key_store_uuid]
KeyStore.load(key_store_uuid) -> [key, iv]
DataStore.load(data_store_uuid) -> [encrypted_data, auth_tag]
Decrypt data and return it to client

Main questions I'm already in doubt with:

is there better/more common/trusted way to encrypt and store data. It should be as fast as possible. Maximum 50 MB blobs are expected to work with.
should iv be stored in KeyStore subsystem or in DataStore subsystem. Is there any difference between these two approaches? NIST says here (page 16) that iv is part of the message. I think that the "message" term is closest to information stored inside the DataStore rather than the KeyStore.
is it safe to use external_uuid as AAD in this scheme? Or should I add another random uuid for that purpose to MapVault
should I encrypt keys in KeyStore by client public key or some master key? Seems this approach used in Oracle TDE scheme. I think encryption with client's public key will make impossible to restore the data even if all three subsystems are stolen.

You're actually best off using an existing product. There's plenty of risk in rolling your own crypto storage system. So many ways to make an error in security or data integrity it's not funny. One commercial product off the top of my head is StorageSecure by Safenet. They specialize in this stuff. There are also quite a few academic and open source projects you can draw on if you're insistent on homebrew.

Fabric Project
http://www.cs.cornell.edu/Projects/fabric/
Has a secure programming language, distributed architecture, protection of computations, and protection of data. Free IIRC.

Tahoe-LAFS
https://tahoe-lafs.org/trac/tahoe-lafs
Distributed, fault-tolerant, encrypted storage architecture that allows clients to insure security of data despite compromised storage nodes. Free.

Securing data in storage: A review of current research http://arxiv.org/pdf/cs/0409034.pdf
A whole bunch of schemes and comparison of protections.

Encrypted storage of medical data on a grid
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.163.9593&rep=rep1&type=pdf
Right up your alley, eh?

I'm leaving off various full system, file system, and file level encryption tools as I figure you know of them. However, I will mention that a poor man's solution to app-level data encryption is to give each app and/or classification category an encrypted volume a la eCryptfs or Truecrypt. And then restrict it to that partition using permissions, mandatory access controls, etc. If you know how to use the tool and read/write to a file, you have encrypted storage. You also know it will work reliably as each will have been battle tested plenty.


Security track record of SSHD on Windows machines? How do the various SSH daemons that run on Windows compare in terms of security?  Vulnerabilities found, reviews by respected reviewers, source code availability, etc.

I only need access to a cmd shell.

(updated to be less subjective)

Well, we're certainly not in a place to judge that. It's hard to do so for most software in an objective sense, and it's rather useless in a subjective one.

With that said, OpenSSH is widely used and widely trusted on Unix systems. Cygwin allows that code to run on Windows. I'd go with the Cygwin + OpenSSH method as you don't have to trust a more obscure vendor to get the implementation of SSH right.


Requirement 12.1.2 of PCI DSS: Is it enough to point to a standard process? Item 12.1.2 of PCI DSS requires that the company's security policy:

  12.1.2 Includes an annual process that identifies threats, and vulnerabilities, and results in a formal risk assessment.

NIST has published a Guide for Conducting
Risk Assessments, which is pretty detailed and could be used as our process. In order to satisfy that requirement, is it enough to just point to the NIST Guide or should the company develop its own customized process (albeit based on the Guide)?

At a glance, the NIST guide you've linked to describes the goals and backgrounds that would be conducted in an assessment, but there's nothing there you can point to and say, "We followed these steps." It doesn't provide a quantifiable, verifiable process that an auditor can confirm.

You'll have to find another resource or develop your own.


Are humans a strong or weak RNG? Thomas Pornin has stated in the past on multiple occasions (I'm not going to source them, he can argue with me if he wants) that humans are bad RNGs.

While I agree that human RNG for password generation in the mind is abysmal usually, I wanted to ask if human-aided RNG by a computer is equally as bad. KeePass has a feature where you seed the RNG by moving the mouse for a while, and while I know that if KeePass is using /dev/urandom it's more or less secure enough, I've used the mouse-seeded RNG in the past.

I've always thought that RNG aided by human input would be better than just standard PRNG as provided by an operating system. How could someone predict exactly how I'd move my mouse, at what rate, how often I'm pausing, etc.?

Human brains are poor RNG. People are bad at generating random values in the privacy of their heads. They just cannot think randomly; though they can convince themselves that they do.

Physical process, on the other hand, are rather good sources of entropy. Take your mouse movements. A few dozen times per second, the mouse measures how far it has moved since the last tick, and sends that information to the server. When your hand shakes, it tends to do so somewhat regularly, but biology is such that each elementary move will be subject to some jitter, which happens to be substantially bigger than the precision of the mouse; even with a lot of training, it is very hard for a human hand to do the exact same move repeatedly (otherwise there would be a lot more people like Yehudi Menuhin). So the bottom line is that mouse movement measures contain some entropy. (Remember that "entropy" is here defined as "that which the attacker does not know"; the mouse certainly knows how much it has moved, since it is that mouse that actually sends the values on which the RNG are built.)

The other half of the answer is aggregation. A mouse-based RNG will use hundreds or even thousands of measures, accumulate them all and condensate them into an appropriate seed that will concentrate all that entropy. This is simple enough: simply feed all the values to a cryptographic hash function, e.g. SHA-256, and you will get a 256-bit seed that has all the source entropy, wherever it was hiding in the measured mouse movements. Hash functions are good for that; they reduce the size but keep the entropy (up to the hash function output size, but 256 bits is more than enough for all purposes).

An attacker may guess that the user will do circles, but will have a hard time getting all the individual movements right, especially since psychology won't help him: the human user himself has no idea how his hand movements are turned into numbers. Since we are talking about hundreds of numbers, the number of possible combinations (i.e. "entropy") raises exponentially. Contrast that with a human user thinking about a new password: the user will choose letters following some inner "witty" train of thought, that the attacker can guess more or less brutally (e.g. if the letters are all the first letters of some words in a sentence from a book, the attacker can automatically try all sentences from all books he can find in electronic format); and, more importantly, the human user won't be bothered to produce more than a dozen or so of "seemingly random" characters.

In passwords, length does not make strength -- but lack of length can be quite effective at preventing strength.


Is Yahoo SignIn Seal effective at phishing prevention? Possible Duplicate:
  Effectiveness of Security Images

Information about the efficacy of Yahoo's SignIn Seal is scarce, the best I could find was this section on Wikipedia's entry on Phishing, claiming that "few users refrain from entering their password when images are absent" and "this feature [...] is susceptible to other attacks" (which?). But even if users were attentitve to it, I'm having trouble wraping my head around the concept.

How does one ensure the seal will only be shown when the user is actually at that particular site? Looking at the source code from Yahoo's login page I see a myriad of techniques being used, but I find it hard to comprehend what are their purposes, and how they work together to achive its goal:

JavaScript is used to check whether or not the page is in an iframe (not showing the image if it is - or if JavaScript is disabled);
The inserted image has a long random-looking token in its src, which I presume is to keep it secret;
The image url expires pretty quickly, so it can't be stolen and used somewhere else.

What I could infer from the above:

The login page request must have been started from the user's browser, or else the cookie that holds the seal wouldn't be sent;

If the attacker puts the page in an iframe, he can't access its contents due to same-origin policy.
Likewise, the attacker can't request it via Ajax, for the same reason.

On request of the login page, the server prepares an unique URL to serve that image (using the contents of the cookie - the image is not permanently stored in the server), with an unguessable token that the attacker could not have access;
The image will only be displayed if the page successfully determines it is not in an iframe; thus, if the user sees the image, he can be confident that the site is legit.

Is my reasoning correct? Are there any known attacks to this scheme? (maybe something involving MitM, etc)

It seems to me that the "correct" attack would be to emulate the behavior that is seen when you attempt to log in on a browser without any cookies already present. This effectively deactivates the "sign-in seal" completely, falling back to the default behavior.

This is the experience users see every time the user starts up a different browser or different computer or clears their cookies (either manually, or because of intervention from some zealous "anti-tracking" tool), so the user will certainly be familiar with it.

Sure, it's slightly different from what you normally see, but you've seen it often enough to recognize it as "real", and there's no other way forward than to put in your credentials anyway. After all, that's what you've done every other time you've seen this screen and it's been the correct behavior every other time.

So, not foolproof, but I'd say this technology is at least a step in the right direction. Not a perfect one, but you could argue that it's better than nothing (you could also argue that' it's not, but there you go). At least they're thinking about it; that's further along than we were several years ago.


Salting password with the first 8 bit of the password itself Do you guys think salting password with the first 8 bit of the password itself will have same result as using stored salt to hash password?

[Clarification]
I am not storing salt but creating from the password itself during authentication.

Followup question, instead of using first 8 bit how about the first (length of the password mod (Prime number)) of bits as a salt? would not this be securer than normal password hashing?

This scheme looks clever, but it isn't.

Salts are usually stored in cleartext. And they serve one purpose - to restrict the usability of precomputed hash tables. There is also the side-effect that no two hashes computed for two different user accounts with the same password will be the same.

By storing a portion of the password as a salt, you are decreasing the security posture of the application, and also complicating matters. The below points assume storage of the salt:

I would consider that the entropy associated with the password is reduced by a minimum value of the entropy associated with the 8 bits; in the Shannon model of calculating entropy of user selected passwords from a 94 character alphabet, this around 4 bits of entropy. The reduction in entropy is due to the model in use - most passwords are not a sequence of random bits, especially if they are chosen from natural languages. Concatenating n-bits from the password to itself to compute a hash will quite obviously make the contents of the password even less random, thus reducing entropy.
Using the first 8 bits of the password as the salt is in itself a poor decision, compared to using the last 8 bits, not that the latter is a good decision. It so happens that under the Shannon model for computing entropy of a password, the entropy per bit reduces as the length of the password increases. If you are using the first n bits as the salt, then you are weakening the password further, as the Shannon model works on the premise that "if the first n bit is known, then how well can anyone guess the other following bits".
Now that you've stored the password fragment in cleartext, you will need to encrypt it. That sounds easy, except that keys have to associated with a management lifecycle where you need to issue them, protect them, and discard them after a particular period; getting of this right is certainly not as easy as using a secure PRNG to generate the salt and storing this random sequence of bits in the clear.

Cryptographic properties of a salt

This is based on Paul's answer and the comments interspersed on this page. This section does not assume storage of the salt, and is rather a note on how salts must be chosen. Any data used as a salt to a password, must satisfy certain cryptographic properties. The most important one is that

  A salt must be unique across the passwords stored in the system.

If the salt is not unique, then one loses the ability to create unique hashes for every password managed by the system, leading to the possibility that a dump of hashes might reveal passwords that are used across accounts or passwords present in dictionaries.

It cannot be guaranteed that the scheme in question has this property. In fact it is easy to assume that the property is bound to be absent in a system with more than 2^8 = 256 users, rendering the scheme quite useless.

Also, if one is under the impression that this scheme can reasonably protect against pre-computed hashes then that assumption is moot. It assumes that an attacker does not have resources at his disposal to compute hashes to compromise all the accounts in a reasonable timeframe. Using a salt with the cryptographic property of being unique would have certainly slowed down the attacker by a large factor, as a computed hash would be valid only for one salt and not for the others (i.e. hashes for any password in a dictionary must be recomputed for every user). If the current scheme were to be employed, an attacker can restrict himself to computing only 1 hash per password in a dictionary, making it no different from not using a salt, thus making it pointless to have a salt in the first place.

This would lead to another property of a cryptographic salt:

  A salt must enhance the resistance of the system against bruteforce attacks and the like.

By using a salt derived from a password, one loses this property, for a hash of every password in a dictionary can be computed in more or less the same amount of time, with or without the salt.

It it to this effect that most systems are engineered to generate the salt of sufficient length using a secure PRNG. One of the comments stated that using a "service name" + "user name" combination is enough. I would say that it is a good thing to start of with. The service name typically acts as a pepper (especially when it is not stored), so that hashes themselves cannot be copied and used across services using the same hashing scheme. The username is decent enough to use as a salt, except in scenarios where the username is public (the root account in *nix, or Administrator in Windows, for example). If your usernames will be public and consistent across several deployments, then using n bits of randomness ought to be the way to go. This is an extension of the second property, in that any choice of a salt must consider resistance to bruteforce attacks across all deployments.

The followup question states -

  Instead of using first 8 bit how about the first (length of the password mod (Prime number)) of bits as a salt? would not this be securer than normal password hashing?

No, the salt is not guaranteed to be unique across user accounts. (See the first crytographic property).


Known examples of spoofed Change Request? A Change Request from a client (in the commercial sense of the word) to an organisation supplying an IT system to that client, can add or modify requirements for that system. Are there any known examples where the content of such a Change Request has been tampered with by a malicious third party and the additional or modified behaviour has been implemented in that system without knowledge or consent of the client?

For IT systems where security is a priority, is it necessary to authenticate such Change Requests, or is that just too paranoid?

Usually Change Requests Workflows have well-defined steps, e.g.:

Plan: Implementor create the Change Request Ticket and fill it with the implementation details (scripts or whatever technical information is needed to fully implement the change)

Discussion and 1st level approval: A technical committee analyzes the proposed change and approve or request it to be re-planned. After this step is impossible to change the contents of the proposed change.

Final Approval: The pre-approved requests are send to a second committee, this time the customer is directly approving the proposed changes.

Implementation: The approved change is implemented and evidence is collected.

Revision and closure: The evidence of the change is reviewed and finally the change is closed.

This cycle would prevent someone tampering with a request due to several opportunities to spot it (either before and after the implementation)


Intercept Android's http/https traffic with shell access Assuming you have a shell access on a rooted Android device. Let's say the shell was given upon an exploitation, eg. Android Webview vulnerability. The question is what is the best way to intercept HTTP/HTTPS traffic with shell access on a rooted Android device.

Simply use SandroProxy (on-device) or mitmproxy (off-device), these will help you perform a MITM attack by generating valid certificates on the fly.

Then use your root permissions to install the CA certificate for your MITM proxy to the system key store (which is located somewhere like /data/misc/keystore from memory) which will avoid the usual warning you get when you install additional certificates.

You should be able to create iptables rules to route traffic via your proxy, or modify the connection settings.

If you're just using it for debugging purposes and you don't mind if the user sees a warning then you don't actually need root, you can just add the CA certificate to the user store.


SSH Bad Protocol Version Identification String- What is it? I need some help identifying some Bad Protocol version identification errors from our server.

We're getting the following:

sshd[xxxx]: Bad protocol version identification '\200\342\001\003\001' from xx.xx.xx.xxxx

I don't know the format that '\200\342\001\003\001' is in, so it will be great if someone could help!

This is octal representation (base 8). During the initial steps of a SSH connection, the client and the server send each other the version(s) of the protocol they implement, as strings. These strings must follow a specific format.

Here, your server received from the client a "protocol version" string consisting of five bytes, of value 128, 226, 1, 3 and 1, in that order. This is not a "protocol version string" which makes sense. Probably, the client was not trying to do some SSH at all, but instead some other protocol.

A lot of virus try to propagate automatically that way: by trying known vulnerabilities of some protocols on random IP addresses and ports. So any publicly reachable server (like your SSH server) will get that kind of noise. Best thing to do is to ignore it altogether.


Are man-in-the-middle attacks against p2p systems realistic? I'm implementing a DHT based on Kademlia following this paper.

The protocol described in this paper uses nonces to protect against man-in-the-middle attacks. The disadvantage is that latency gets doubled by effectively introducing a second round trip time.

Now my question is, are man-in-the-middle attacks against p2p systems where each peer knows quite some peers and no long-term connections realistic? Was the nonce exchange added for purely academic purposes to propose a "fully secure system", or does it actually prevent a real risk?

One of the challenges with p2p systems where there are numerous peers, and numerous short term connections, is that authentication may not be manually checked (it would introduce a high overhead) so placing reliance on automatic protection is quite common.

Where a user connects to only one other, confirming a key or certificate fingerprint to avoid a MITM attack may mean a quick phone call, but imagine doing that for high numbers of connections.


Writing Android Exploits I want to learn how to detect and write exploits for the Android OS. I am a bit familiar with Linux and have some knowledge in scripting in ruby and python. I had learnt how to write Exploits for basic buffer overflows and SEH. However I am finding very little material for finding and writing Android Exploits. Any ideas?

Found a few presentations by googling. Maybe some of these may help or get you started. Most android devices are ARM based so resources on ARM assembly/ shellcodes may also be useful. Hope it helps some.

Popping Shell on Android

Shellcode on ARM


Is there something insecure about storing secrets in plain text on the host FS? There are recommendations on this website and in the internet suggesting to never store credentials (e.g. login/password to the database that certain web application is using, or S3 access key on non-AWS instance, etc.) in plain text on the filesystem, apparently due to possibility to recover password from the disk.

The alternative suggest transmitting secrets from a some sort of remote secret manager over the network, I believe this model expects application that makes use of corresponding secret to store it in memory. Variations of this scheme also support storing secrets in encrypted files on the target host's filesystem and transmit encryption key to the application in some secure way over the network.

Given that I'd still like to store credentials unencrypted on the local filesystem - let's say due to framework limitation that expects unencrypted password in some local file - would it be possible to still store secrets in plain text in certain file and mitigate the risk by:

Using encrypted filesystem - so malicious actor who steals the disk still won't be able to read secrets on the encrypted partition.
Using ram FS (let's forget about necessity to transmit secrets first for now).
In addition to either 1 or 2 limit access to file to a certain user which is used to run the application.

P.S. there are similar questions about this matter, e.g. Storing database password in plain text? (this one is perhaps too vague and therefore it did not receiving a clear answer) and Is it okay for API secret to be stored in plain text or decrypt-able? (more broad in scope; the answers though didn't address particular aspect I'm asking about).

In addition, I want to clarify that (1) password IS NOT stored in the application configuration, let's just say it is distributed via some secure mechanism to the host during application's deployment; (2) end user who uses web application I'm referring to does not have access to the host.

My primary question is whether there is something inherently insecure in filesystems that essentially leaves me with options that expect me to never store credentials (for accessing other services from my applications) unencrypted on any filesystem. In order to narrow down the scope, let's limit this question to modern Linux OS.

OWASP comments on this in Cleartext Passwords in CATALINA_HOME in the context of managing Tomcat's web server database credentials.  Their view can be summarized as

  best practices is to never to store clear text passwords, but it is
  very difficult to avoid

Their primary recommendation is to use file system security to secure the credentials file and limit the database user permissions to the minimal required.

If you have heard the expression, "it's turtles all the way down", it nicely summarizes the OWASP view that hiding the password in another place isn't really resolving the key issue and may provide a misplaced trust that the issue has been solved.

Enterprise security teams are sometimes humorless and likely lacking in  appreciation for philosophical arguments involving turtles and the problem of infinite regression. Therefore, there are several password vault solutions with integration for web servers including Tomcat Vault, OracleWallet, CyberArk, etc.


How to carry out a CSRF in a stealthful manner I am a math grad student dabbling in network security. I was playing around with login cross site request forgery, and the whole point is to log somebody in. (I am a complete novice in HTML and JavaScript).

My code thus far:

<form method="Post" action="example.com">

<input type="hidden" name="username" value="NotAHacker" />
  <input type="hidden" name="password" value="H4x0r" />

</form>

<script>
    document.forms[0].submit();
</script>

This code works perfectly, I want to know how to do this, without a window popping up, or at least do it in such a way that the page is blank and the victim is not tipped off of what has happened. I hear JQuery could help with this? Again, I don't know HTML or JavaScript and could use some advice.

The easiest way is probably a tiny or hidden iFrame.

Embed an iFrame on your page with a src of your other page containing the CSRF code. The iFrame will get redirected but the user is unlikely to notice because they won't be able to see it.


Should we keep our penetration testing environment separate from other test infrastructure? Given that there are N number of hosts on a given network being used for different purpose, should we place a machine for penetration testing or vulnerability scanning on same LAN or should we have that machine/host on separate network and specifically whitelist that IP address on the firewall in between?

One reason for thinking about placing them on same network is the scanning speed and other is not triggering any tripwires in between the scanning machine and the target host. Any other thoughts why or why not to?

This really depends on the type of pentesting you're going to do.  Are you trying to identify the vulnerabilities from attacks coming from a machine in the same LAN?  Then you put the pentesting host on the same LAN.  Do you want to see if your public-facing webserver is secure vis à vis of external attackers?  Then do a pentest from the Internet.  And so on.

In general, you should do a pentest in the most typical situation.  If the scans trigger tripwires in any part of your network, that's an important information as you'll know that the IDS is working properly.


Somone accessed my desktop right in front of my eyes I was using my desktop to do some work. I left it and sat on the sofa, the screen went off and after few minutes it went one I freaked out when I saw the mouse moving around on the screen, then it went down to the taskbar, opened my download manager and ran TeamViewerQS.exe.

When I saw that happening, I freaked out and it felt spooky. I shut down the pc and unplugged the network cable and started the PC backup.

I don't have (or use) TeamViewer, I use Windows 10 for my operating system and I have Kaspersky total security running. I'm the only user for this desktop and I never gave access to any other user for remote access.

Could you please help me understand what is happening?

Yes, your machine has been compromised by an attacker.  You may have fallen for a fake "Computer Support" scam, or opened a phishing email attachment, or clicked on a bad link, or even simply been the victim of a "drive-by" malicious web site advertisement.  I know TeamViewer is a common tool used by the fake support scam people; it is also used by other attackers.

You absolutely did the right thing by unplugging the network cable.  Well done!

Unfortunately, since there is no way of knowing what they stole from your computer, you need to assume they already got away with some profitable stuff.  Your next step should be to use a different (non-infected) computer to immediately change your banking and financial website passwords first, then your credit card / payment website passwords, your ISP and mobile provider passwords, and the passwords to each of your online shopping sites.  Change the passwords to your social sites last, they're probably not as important as your money.

Consider contacting your local police because you have been the victim of a crime.  Having a case number may be important if you need to file an insurance claim or report the identity theft to your bank or other businesses.  But don't expect much help from the police, as they probably won't have the resources to investigate it; and unless you know money was fraudulently stolen from you, they won't prioritize it.

Once the important risks are taken care of, you can start to copy off any valuable data files you have from the infected machine - personal photos, documents, etc.  Save them to a thumb drive.

Finally, you should wipe and reformat your computer's disk and rebuild it.  You might be able to enlist a computer-savvy friend's help for this.  Or consider bringing it to a computer repair place who specializes in recovering from attacks.  They also might be able to help you preserve any licensed content you have stored on it.  But be warned their help could quickly add up to higher than the cost of a new computer.  Be sure to get a quote or arrange spending limits with them in advance.


OWASP ZAP uses non-existent parameters While running scans with ZAP, I noticed that many of the reported vulnerabilities involve sending malicious content as a value to a parameter named "query". For example:

http://<url>:<port>/path/path/path?query=query+AND+1%3D1+--+

The api method in question, however, does not have a parameter that goes by this name, so I was wondering how the tool could possibly detect a vulnerability with this. ZAP did, in fact, report an SQL Injection vulnerability with "Medium" confidence from using a url like the above, and has had similar results with path traversal and xss.

Could this be a consequence of me not setting up ZAP correctly? Is it possible to for an api to be made to read parameters that the developers did not define? Is ZAP just guessing at the parameters the api uses?

Yes, its added by this code: https://github.com/zaproxy/zaproxy/blob/develop/zap/src/main/java/org/parosproxy/paros/core/scanner/VariantAbstractQuery.java#L148-L153

This is added to see how webapps react to queries - if they handle them badly then yes this can introduce vulnerabilities.

If you think ZAP has reported false positives then please report them too us: https://github.com/zaproxy/zaproxy/issues/new?labels=bug&template=Bug_report.md

Note: As of ZAP 2.8 the addition of parameters to requests that didn't originally have them is now optional (and default off). Ref: https://github.com/zaproxy/zap-core-help/wiki/HelpUiDialogsOptionsAscaninput#add-url-query-parameter


CVSSv2 score of 10, but no CVSv3 score We are working on our Vulnerability Management process and as part of that, I was going through the reports from our infrastructure vulnerability scanner. In the reports, I noticed that some of the CVEs does not have a CVSSv3 score, but they have a CVSSv2 score.
Eg: CVE-2008-6536.
What does that mean? Does it mean that if we are planning to handle our vulnerabilities based on CVSSv3 score, then we don't have to consider CVE-2008-6536? This particular CVE has a CVSSv2 score of 10, but it says 'Not Applicable' under  CVSSv3.

CVSS v3 was released in 2015 so vulnerabilities prior to that were only rated according to the then-current CVSS v2. Also, my guess would be that "N/A" in this context stands for "not available" instead of "not applicable".
Of course, you should consider CVEs prior to 2015.


Software to simulate attacks such man-in-the-middle or DoS Sorry for novice question. I am completely new here.....

I am already familiar with Asp.net, JavaScript, Java, C++, etc.

I know the theories behind attacks and protocols, but I want to see them in simulation systems.

Do you know any simulators where I can try these (network attacks such as DOS, man in middle) on them?

In one way of answering your question, you can look at something like Kali Linux , for a suite of attacks, and Metasploitable for a vulnerable target. Place both in a virtual environment (VirtualBox?) and simulate the types of attacks that you want.

Alternatively, you don't need a specialized target, but simply a generic target using a vanilla OS.


Anonymity of ballots when voting with BYCRYPT hashes Hello Security Experts!

I am implementing a small web application where users can cast votes. On the one hand, I want ballots to by anonymous. So the username is not stored with the ballot. But on the other hand I want that each user can verify for himself, that his vote was accounted for. So I thought about this process:

When a user casts a vote, then he must enter his password. (Of course his password is never stored directly anywhere!) The backend creates a HASH  value of the users password. And only that hash value is stored with the ballot. All ballots are publicly available, including their hashes.

So when a user wants to verify that his vote was accounted for, then he can simply recreate his hash value and look it up in the list of public ballots.

Initially I thought about MD5 but then I found that there are stronger, better Hash algorythm. Now i use BCRYPT.

But the Java implementatin of BCRYPT needs a new seed value everytime you want to hash a password. I found out that JBCRYPT stores the seed together with the hashed password.

=> Is that ok? Is that normal?
=> Could I create one initial seed once, store that and then reuse the same seed value everytime a vote is casted?  Or would that be a security risk.

Why do I need that? My functional requirement is a little different than with normal password hashing. When checking a hashed password then you know where to look: Does that specific hash value (at that user) fit the provided password.   My requirement is different:   The user has a password. When this password is hashed, is the the hash value then contained in a list of hash values.

How can I implement this?

You shouldn't make public your users' hashed passwords, even if they were hashed using a strong algorithm like bcrypt. An attacker could easily download them and bruteforce them, and recover some of the passwords.

The bcrypt "seed" is the salt used to protect against rainbow table attacks. A salt MUST be unique, so using the same salt for every hash is a really bad idea.

You should look at this question who faces the same problem than you, and has already some answers.


File integrity assurance I have the following scenario : Two parties want to exchange files.

First party publishes a file on a secure server

First party sends to the second, a hash of the file in order to be able to verify integrity.

Second party downloads the file from the secure server

Second party computes the hash of the downloaded file and sends the hash to the first party to confirm integrity.

What is the best way to implement this scenario? -what is the best hash function to compute for file integrity?

-what is the best way to exchange the hash between the two parties?

The scenario you describe is a "common download secenario".
The "first party" simply has to publish the hash of the file on the same server where the "second party" can download the file.

The second party can then calculate the hash of the file and verify it with the published hash on the server.

If your assumption of an "secure server" implied that information on the server cannot be manipulated or replaced by an attacker and the communication is secured by TLS, then this workflow is secure.

There are many examples of this practise e.g. look at https://www.openssl.org/source/, where the sha256 hash of each .tar file is published.

  what is the best hash function to compute for file integrity

common used hash functions like sha256

  what is the best way to exchange the hash between the two parties

already answered above, just publish the hash of the file on the server.


Probable hack: email "from" names being corrupted Something very weird and troubling started happening on my wife's Gmail account today. She received an email from G. Arnold, who is a regular correspondent, but in her inbox it showed as being from "Crazy Arnold". That sounds quite funny and off-beat, but it's not in character for this particular person. Plus, when she opened the mail, it briefly flashed up with the sender's real name, then switched back to "Crazy". In the screenshot below, I captured the moment before "G... Arnold" switched to "Crazy Arnold". In addition, the "to" address shows as "that Bnos", instead of "Bnos ...", the organization on whose behalf she is receiving the mails.

I checked in the mail headers, and the "from" address is normal. There is no sign of the word "Crazy" anywhere in the source.

This is not the only email thus affected. Many other senders are showing up with strange "from" names.

The common thread I can see between all these emails is that they have passed through a particular domain that I administer.

This smells very much like a hack. Any idea what kind of hack this could be, how to remedy it, or what preventative action to take?

It might be a browser extension. Have you checked those for anything unusual?


When secure email, is not really secure We have a vendor who sends us "secure" messages. The messages come as an email message that contains a link to an SSL encrypted website that has the real message. There is no username/password on the linked site, or any other form of authentication as far as I can tell.

I'm sure they do this so they can check off a box on some compliance checklist, but I want to know, can this truly be considered secure?

My thinking is that since the link itself is sent in the clear, then it is no different than if they had sent the message in the email in the first place. Any attacker who might be able to gain access to my email, either at rest or in transit, can capture and then visit the link.

So is this secure, and if it is at least at some level, what security problems might it be solving? Are there other security measures, not readily evident, that they could be taking to ensure only the original recipient can use the link?

Because several answers have mentioned it. In this case there is no IP address white listing or behind the scenes proxy authentication.

Also, there is an expiration date listed on the link, but it is fairly far in the future.

Since raw emails are not encrypted, what you can read in an email could have (conceptually) been read by anybody. However, to read the email, the attacker would still have to connect to the HTTPS server, which leaves tracks (the IP from which the attacker connects will be known to that server -- of course, that IP will probably be that of a Tor exit node). The link-in-email system prevents passive-only attacks: the attacker has to send some IP packets of his own at some point. This is not a huge increase in security...

Usually, promoters of solutions such like the one you describe do it for security, but not your security. They want to know when the email was read. This is a preventive measure against people who read embarrassing emails and then claim they never received them. It won't be much of a proof, but it may be sufficient to counter evasive maneuvers from some uncooperative co-workers.

If you want a system which guarantees that only a specific individual will be able to read the email, then you need to define what specific individual you are thinking about. In the world of computers, everybody has a computer, and they are not immediately indistinguishable from each other. People have physical identities which are not part of the computer world, so a link must necessarily be made at some point. Standard secure email solutions like S/MIME do that through a public-key infrastructure: a recipient is defined by being "the guy who controls the private key corresponding to the public key which is in that certificate". This moves the problem of physical identification to a single preparatory step during which the certificate is issued.

A possible model is that you met the recipient in person once, and he gave you his business card; on the card is printed the fingerprint of his OpenPGP public key -- you then find the key from a public key server, and check the fingerprint. There are many variants on this concept, but a non-computer physical contact is necessarily involved.


Using username as salt safe enough? Instead of creating a separate salt generator for each user, can't I just use their username as a salt? It would be unique for everyone, and achieves the purpose of the salts.

    <?php
$hashedpass = sha1($username.$password)
 >?

If the username is too short to be used as a salt, I can just add a global string to the username.

$salt =$username.'asdf1234'
$hashedpass = sha1($salt.$password)

Would this be sufficient for security?
It still creates a unique salt for each user and prevents rainbow table attacks.

User names are predictable. I would prefer using random value as a salt. An attacker could begin the generation of precumputed hash table targeting one user (admin?) even before obtaining the hash&salt to crack.

So, you should NOT.

Edit:

The main purpose of having a salt is that rainbow tables are useless. From my point of view, using a guessable value (even with static value added) as salt is bad practice as you allow an attacker to "prepare" the hashes before obtaining your database.

In some scenarios : if you distribute your code and you have a default "admin" account, an attacker will be able to reuse the rainbow table against all the installations of your software.

Other example from @Anti-weakpasswords : Pyrit, "a WPA/WPA2 cracking tool, tool advantage of the WPA/WPA2 protocol using the SSID (username equivalent) as the salt to allow the precomputation of reasonably sized dictionaries against common SSID's - linksys, dlink, 2WIRE047."


Why does Microsoft limit password length? Possible Duplicate:
  Should I have a maximum password length?

According to a recent TNW article:

  Microsoft doesn’t like long passwords. In fact, the software giant not
  only won’t let you use a really long one in Hotmail, but the company
  recently started prompting users to only enter the first 16 characters
  of their password.

This practice seems counter-productive.

Would they have made this decision based on a limitation or particular behaviour of their hashing algorithm?

Purely legacy reasons. They are working to increase it.

From: http://windowsteamblog.com/windows_live/b/windowslive/archive/2012/07/15/keeping-your-microsoft-account-more-secure.aspx (see comment made by Eric Doerr in response to @MondayBlues):

  Password length - We are working on increasing this. Unfortunately,
  for historical reasons, the password validation logic is decentralized
  across different products, so it's a bigger change than it should be
  and takes longer to get to market. It's also worth noting that the
  vast majority of compromised accounts are through malware and
  phishing. The small fraction of brute force is primarily common
  passwords like "123456" not due to a lack of complexity.


What are the risks associated with a vulnerable javascript in a client context? Background: it is not difficult to introduce vulnerabilities in backend/API code when not  coding with security in mind. This typically leads to vulnerabilities such as XSS or various injections (or others).

It is also possible that this backend/API code is intentionally written as malicious - this is something I put on the side, concentrating on the first case.

Question: is it possible (and if so - how) to introduce vulnerabilities via a sloppy Javascript code? In other words: is there Javascript code which can be used by an attacker in a browser context, and in that browser context alone?

Vulnerabilities which lead to server-side issues (XSS, ...) are not in scope, I am wondering about a scenario where the attack would be made possible because of flaws in JS code per se.

In contrast, I know how to use malicious JS code to steal information from the DOM (in the case of, for instance, some widget portal where the JS code running is not vetted). This is not the case I am interested in.

Yes. One type is DOM based XSS. In this case user input is reflected on the page through JavaScript, without having been to the server. Consider the following:

document.getElementById('#message').innerHTML = location.href + " does not exist";

In this case, an attacker can put HTML on the page by putting it in the URL. This makes it possible to run JavaScript in the context of the site.


How can Huawei (or any other telecom vendor) provide verifiable security assurance? IMHO, It is in Huawei's (and all other equipment manufacturer's) best interest to preclude \ prevent any party from remotely breaching security.  All government actors monitor communications by compelling ISP & Telco's via force.

How can equipment manufacturer's provide assurances that intentional remote access vulnerabilities are not designed into systems for their native government?

Providing fully verifiable security assurance is impossible with today's complex systems. Even if the full source code is offered for audit (which Huawei seems to offer) this might catch the obvious backdoors but it will not catch bugs that can lurk deep inside and which might also be used to provide backdoors into the system. And it will also not catch explicit or implicit (i.e. bugs) which were added in patches unless these patches are again audited - which is costly and time consuming. And this only covers software - there is also the hardware and firmware which is complex too and might also have explicit or implicit backdoors.

Still, providing the software and design documents for audit might actually add enough trust that the system does not have explicit backdoors. When doing common criteria evaluations it is common that the auditor has access to software and design documents - at least for the higher levels of certification like EAL4. Thus, while not being fully verifiable secure or formally verified it might be considered sufficiently secure for the purpose and the vendor might be considered trustable.

But of course, this means that not only the vendor has to offer all this access (many do) but that there is actually an interest in even considering the vendor as trustable. There are several factors which can play against this: political and economic factors but also the goal to reduce potential risks. The first ones should be clear, i.e. one can use trade restrictions as a political weapon and one can also want to favor local vendors against foreign vendors for economic reasons.

But reducing the risk is also relevant: one does not want to have a vendor with potential ties to or dependency on a political, economic and military foo to have control over sensitive or critical infrastructure. The vendor might be considered trustable now. But this might change if conflicts increase and in this case the foo has an advantage if it could control an essential part of your infrastructure - like the mobile network, communication equipment, electric power stations etc. This is especially true with vendors which are located in countries where it is likely that the government will lure or pressure the vendor to play in the states interest, i.e. China, Russia but also (as also the Snowden affair has shown) the USA and Israel (which has known tight connections between cyber-security companies and the military).


Can .htaccess and .htpasswd really protect me? I want to set up a kind of personal wiki where I can store various sensitive information. However to make it 100% portable and and just plain convineant, I want to put it on the Internet. I'm sure at this point many of you are like "JESUS NO! ARE FOR REAL?" -- hence the question.

Would using a login prompt really be enough security for me have passwords and maybe even banking information up there? I know there is the obvious brute force which is the caveat to many login systems, but how reliable could mine be? If that wouldn't be enough, is there some way of encrypting my website?

I can store various sensitive information. However... I want to put it on the Internet

Yikes, as they say...

In this specific scenario, there are three issues:

The security of your authentication mechanism. You probably need to use TLS to protect this resource, since http basic auth really is basic - plain text, over the internet. Likewise, digest auth sends digests over the internet. Not much better. There's also the threat of interception unless you use TLS, so basically, TLS (https) is pretty much mandatory. The next step here is whether or not infinite re-tries are a possibility - in other words, can you prevent a dictionary attack? SSL is all very well, but unless you use client side certificates anyone can connect and repeatedly try passwords, so you need to ensure whatever web server you're using is configured to deny requests after X attempts. What you have available and can enforce should inform your decision to go ahead with this.
The security of the storage mechanism. If you're using a VPS, your hosting provider can almost definitely log in and definitely have disk access to your VM. If you have a dedicated server, that's a different issue. If you're planning on a shared host, be aware a compromise in one of the other 1000 or so websites running from that box could potentially expose your information. Encrypting that content will require you to have available a key to decrypt it, either on the server (this issue applies) or on the client (the issue below applies). Again, what setup you have available should inform your decision.
The security of the system on which you access that information. A similar question cropped up a while ago for a different purpose, but basically there is no way to force the client system to securely forget the information unless you have full control over it. As an end user and using TLS, you have a greater idea of what is going on, but even so, should you choose to access that information at a cyber-cafe, there are scenarios in which that data can be recovered. Any read is likely to store that information locally for processing and must decrypt it locally, even if it isn't cached, so there is a threat of interception. How much of a threat you think this is again should be something you take into consideration.

How much of an issue these factors are depends on how valuable the information you're storing is to you and to what extent you think you're at risk. For example, my main online bank and online store accounts all point at one email. I wouldn't be comfortable accessing any of those, or their login details, on a cyber cafe computer. However, I have a day to day email for mailing lists and other such info that is far less critical if compromised. So I would have fewer issues using that. If the risk is acceptable to you in storing this information on a wiki, then do it.


Realistic for organizations to avoid links in emails pointing to less known sites? Over the years, I found myself constantly pointing out to organizations that emails containing links with 3rd party domain names that are relatively unknown are problematic.  That's how social engineering occurs.  For example, surveymonkey is well-known, but survey.alchemer-ca.com not so much.
I'm beginning to wonder how realistic this is.  If it's just noise, then there are negative repercussions for being the lone wolf baying at the moon.  Organizations typically have more demand than their IT/security staff can service.  Requiring that links point to the organization's domain for redirection to a 3rd party service is not feasible in most cases.
A further complication is that it adds yet more process, compromising the agility with which staff achieve outcomes, e.g., conduct polls, surveys, and organize events.
Finally, even if such a process was put into place, unless there is constant reminder of its necessity, it is easy for staff to forget, to make "exceptions", or for new staff to not be indoctrinated into its use.
In view of the challenges, what is a feasible way to avoid the vulnerability to social engineering posed by 3rd party links in emails?

It is far more nuanced than you have described. And you need to provide more clarity for people on what "less known" means.
The feasibility of this process will depend on the company and industry. In some regulated industries, places have Allowlists on their firewalls and email filters to only allow links from the Alexa Top X plus known partners. Or just known partners. In other places, such a process would simply not work.
I regularly advocate for firewalls/filters to block "new" sites, where the domain is less than a month old. This is one form of defining "less known" domains.
So, whether your suggestion makes sense depends on the risk profile of the organisation and the impact of doing what you suggest versus the impact of something going wrong if they don't. Just offering vague blanket advice to all parties equally is where you are going to have trouble.
Define the risks and tailor the risk response to the organisation. Ultimately, that's what is going to be feasible.


Global check of input/output of known hash functions Is there a website, application, or script that will allow you to give an input/output for a hash function, run these against known functions, and return any matches?

Here's one attempt to list the functions:

http://en.wikipedia.org/wiki/List_of_hash_functions

Hash ID is a new, open sourced, project trying to achieve exactly the thing that you are looking for:

http://code.google.com/p/hash-identifier/

Encryption formats supported:

ADLER-32
CRC-32
CRC-32B
CRC-16
CRC-16-CCITT
DES(Unix)
FCS-16
GHash-32-3
GHash-32-5
GOST R 34.11-94
Haval-160
Haval-192 110080 ,Haval-224 114080 ,Haval-256
Lineage II C4
Domain Cached Credentials
XOR-32
MD5(Half)
MD5(Middle)
MySQL
MD5(phpBB3)
MD5(Unix)
MD5(Wordpress)
MD5(APR)
Haval-128
MD2
MD4
MD5
MD5(HMAC(Wordpress))
NTLM
RAdmin v2.x
RipeMD-128
SNEFRU-128
Tiger-128
MySQL5 - SHA-1(SHA-1($pass))
MySQL 160bit - SHA-1(SHA-1($pass))
RipeMD-160
SHA-1
SHA-1(MaNGOS)
Tiger-160
Tiger-192
md5($pass.$salt) - Joomla
SHA-1(Django)
SHA-224
RipeMD-256
SNEFRU-256
md5($pass.$salt) - Joomla
SAM - (LM_hash:NT_hash)
SHA-256(Django)
RipeMD-320
SHA-384
SHA-256
SHA-384(Django)
SHA-512
Whirlpool
And more…

Enjoy!


Who should I give my password to I've got a dilemma, should I give my password to my local IT help desk (I am seeing them face to face, and I know that they work for the same company as myself).   They want to perform a routine migration for me from one device to another device.

Edit: Yes this may well be considered a duplicate.  I know that it is best practice not to give my password to anyone, but what should the advice be when it is a Trusted person (for a routine operation).

The migration is for my corporate profile from one device to another.

Thanks,

I have 2 solutions for this.

1)No. Don't give them the password.
If they need your password to perform migration then they should just ask you to input your password.
Note: If the process is lengthy and you need to input it multiple times check option 2.

2) Don't give them "your" password, but give them the password for the device.
Change the password to something generic before handing the device to them. This way if the process is lengthy the person performing the migration can use it whenever he needs. Also, "YOUR" password stays with you (that's why it's secret) and you can use it again when the new device comes. (I strongly recommend changing the password from time to time).
Tip: Make the password something funny so the guy working on your device smiles when he does it. It doesn't hurt trying to make someone smile.


TPM and storage of keys A TPM hardware device has very limited non-volatile protected memory just sufficient to store the EK (Endorsement Key) and SRK (Storage Root Key). How does a TPM allow nearly unlimited number of symmetric keys to be safely stored on an otherwise very vulnerable HDD?

The Storage Root Key (SRK) is used to wrap TPM protected keys which can be stored outside the TPM. That data stored outside the TPM can be decrypted by passing it back through the TPM again for a decryption operation.

Keys wrapped by the SRK can themselves be used to wrap other keys, too. This method of wrapping can be used to create a key hierarchy of parent key and child keys. To load a child, first load its parent. Once the child is loaded, the parent key can be unloaded from the TPM to free up TPM chip resources.


Is it possible to restrict a client-side certificate (for web auth) valid only for a given site name? If I have 2 websites, a.example.com and b.example.com. Those sites use TLS and SNI, and require client authentication with certificates created with my own CA.

The use case is that some clients have access to *.example.com, other clients  have access only to a.example.com.

Is it possible to create a certificate so that authentication is valid only when used on site a.example.com, and rejected when trying to connect to b.example.com?

Or would I have to create a second CA for this purpose?

In this case, is it possible to have a.example.com validate certificates against either one of those 2 CAs? (if yes the answer might be specific to nginx? or doable if one CA is a subordinate of the other?)

Certificates establish authentication (tying a person to an identity), which is the wrong approach to limit access to b.example.com - a user is still themselves on both sites, and all authentication's concerned with is having them prove their identity. Limiting access is authorization, which you should do on your end by actually checking the ID contained in the certificate against your own database to see if they should have access. The certificate contains subject info which should probably include some form of username, and you should be keeping the list of users and who's allowed to access what. That also allows you to change the scope of someone's access without needing to reissue a cert.

Client certs do not tie to domains; that's because they aren't meant to authenticate a server. I should be able to use my certificate anywhere that'll accept it, and with client certs that is what happens.


Unauthorized domain comes up as my website While checking my website's traffic, I found a referring website that had sent over 400 visits to my site. When I clicked on the URL of the referring website, the site looked almost exactly like my own website.

I investigated the URL and found it had been created 12 days earlier.  While I am having an attorney send a "take down" letter to Tucows, OVH, Privacy, Inc. and Exabytes (abuse reports to all of these have resulted in no action), my question is:

Why was this domain, www.wigsforwomenny.com, created and somehow shows the same pages as website, www.karenswigs.com?  Everything is the same except for two digits in the telephone number.

Note: Layman's terms appreciated!

I don't think they are actually redirecting to your site. If it was a true redirect, then the phone number couldn't be different. My guess is your website was scraped and copied to another site. They registered a new domain and used the content of your site. Then they created some spam SEO links to trick Google into moving them up higher in the rankings to get traffic to their site. They purchased a new phone number that is very similar to yours and the plan is to wait for the phone to ring. When it does, they take an order over the phone and now they have stolen someone's credit card number. This could go one for days or even weeks before Google figures it out and shuts them down.

It may be too late now, but I'd call the phone number and see who answers.


How to prevent users to access my files? I run a magento shop and figured out that there is a security risk. Users can download the logfiles under /var/log/. If they go to https://www.example.com/var/log then a 404 site shows but if they know the exact name of the logfile then they can download it e.g. with https://www.example.com/var/log/system.log.

I readed that you can prevent this by placing a .htaccess file in any folder with the following content:

Order deny,allow
Deny from all

But I can still download the log. There is also another log in the same place named setup.log which I can't download.

Both files have the permission set to 644

How can I secure my webserver?

https://magentary.com/kb/securing-magento-cacheleak/

I think this other question answers yours

https://serverfault.com/questions/22577/how-to-deny-the-web-access-to-some-files

You could use Files/FilesMatch and a regular expression:

<Files ~ "\.log$">
    Order allow,deny
    Deny from all
</Files>

or redirect any access of .log to a 404:

RedirectMatch 404 \.log$


How do I hash a password in C#? I assume that the best way to handle passwords for a website is I create a hash of the password and save that hash in my database. Then when someone tries to login, I do a hash of the password they entered and compare.

Is this correct?

And, is there sample code anywhere showing how to do this in C#?

And should I add some standard text to each password so the text being hashed is always at least 20 chars long?

Update: The other links don't have code so here's what I implemented for this question. I don't include the username because that can change, so just salt:password. the : works because uuencode does not include a :.

public static class EncryptionUtilities
{
    private const int SALT_SIZE = 8;
    private const int NUM_ITERATIONS = 1000;

    private static readonly RNGCryptoServiceProvider rng = new RNGCryptoServiceProvider();

    /// <summary>
    /// Creates a signature for a password.
    /// </summary>
    /// <param name="password">The password to hash.</param>
    /// <returns>the "salt:hash" for the password.</returns>
    public static string CreatePasswordSalt(string password)
    {
        byte[] buf = new byte[SALT_SIZE];
        rng.GetBytes(buf);
        string salt = Convert.ToBase64String(buf);

        Rfc2898DeriveBytes deriver2898 = new Rfc2898DeriveBytes(password.Trim(), buf, NUM_ITERATIONS);
        string hash = Convert.ToBase64String(deriver2898.GetBytes(16));
        return salt + ':' + hash;
    }

    /// <summary>
    /// Validate if a password will generate the passed in salt:hash.
    /// </summary>
    /// <param name="password">The password to validate.</param>
    /// <param name="saltHash">The "salt:hash" this password should generate.</param>
    /// <returns>true if we have a match.</returns>
    public static bool IsPasswordValid(string password, string saltHash)
    {
        string[] parts = saltHash.Split(new[] {':'}, StringSplitOptions.RemoveEmptyEntries);
        if (parts.Length != 2)
            return false;
        byte[] buf = Convert.FromBase64String(parts[0]);
        Rfc2898DeriveBytes deriver2898 = new Rfc2898DeriveBytes(password.Trim(), buf, NUM_ITERATIONS);
        string computedHash = Convert.ToBase64String(deriver2898.GetBytes(16));
        return parts[1].Equals(computedHash);
    }
}

ps - I considered adding "The World Wonders" to the text hashed because it's the most famous salt of all time. However, I figured it didn't add anything and encryption is not the place to bring in historical strings.

Yes, you should add a text to each password so that the text being hashed is always at least X long, this is called a salt, and it should be unique to each user.

A database entry might look like this:

username : password : salt

bob : qiyh4XPJGsOZ2MEAyLkfWqeQ  : zyIIMSYjiPm0L7a6

the salt should be randomly generated when the account is created, and then you would concatenate the salt with the user's password input, run it through a 1-way hashing algorithm (multiple times to slow it down), and then save the output in the password field, and duplicate the procedure upon login, then compare the two strings (make sure to do full comparison, don't stop once you notice the strings no longer match, in order to prevent a timing attack)

for an actual implementation I would check  Ángel's link


How to prevent unauthorized users from accessing an image on my server just by URL? I have a few dynamically generated images on my server (of high business value), which are supposed to be viewed only via our mobile app. The image is simply loaded from the URL as PNG. How can I prevent people from accessing the same image just by using the URL (if they find it out)?

I could use a PHP script which requires a token to serve the image (rather than access it directly). But If someone goes and reverse engineers the mobile app, token can also be found. I could try and hide it really well, but isn't there any other, better solution?

You have to work with that images the same as it should be for restricted content. There are two major points:

Protect access to the content (the images)
Protect content against brute force not to allow user guess about image path.

The both points could be covered with proxy request through php script.
The first point can be solved with authentication and protection content with a token and ACL (access control level). Make sure the images out of webserver visibility not to access image directly. It could be helpful to rename image after upload and save original name and new name in DB. In this case you can call it from app by original name and access it by new unique real name.


How secure is OS X's Keychain access control? On OS X, when an application requests access to a Keychain item, the user is prompted whether to grant or deny that access.

Supposedly, the system saves not only the binary path, but also its hash in the ACL entry that is created after the user confirms the request; according to Apple, this protects against modified binaries gaining access to user passwords and/or certificates.

Is this really sufficient to prevent an attacker with user (but not superuser) permissions from retrieving all stored passwords?

On Linux, for example, there is the environment variable LD_PRELOAD which can be used to load additional dynamic libraries that overwrite some standard library functions with custom code; using that, it would seem to be possible to change the code that is executed within a given binary without modifying the base executable itself.

Is there a similar mechanism on OS X that would enable such an attack (maybe one of the methods mentioned here)?

The security boundary is root, i.e. securityd running as root. If securityd and it's ACL are implemented correctly, there is no way for another application to access the key from the keychain. However, Mac OS X has had several privilege escalation vulnerabilities which would allow a local user attacker to access securityd and thus the item from the keychain. It is reasonable to assume that a moderately/highly skilled attacker could still find existing privilege escalation 0day.


How are Google always identifying me? I'm trying to create multiple Google accounts

Here's my setup:

I use Firefox with the FoxyProxy plugin and a bunch of IP's.

I use the Firefox Random Agent Spoofer plugin, with the following settings:

{

Random browser profile:

Headers:

Options:

(I can only post 2 images, so the last one is here: i.stack.imgur.com/miGH2.png)

}

After each account creation attempt I do the following:

Close down FireFox
Run CCleaner and clear:

{

DNS cache
Temporary files
All Firefox data
Adobe Flash player data

}

Open up Firefox again, change proxy through FoxyProxy

The Random Agent Spoofer plugin automatically assigns me a new browser profile.

However; every time I attempt to create a new Google account I get asked to verify my phone number after which the number is denied.

It is very obvious that Google somehow are tracking me between each session as I am entirely certain that neither the proxies nor the phone numbers are the problem.

So I guess my question is: How are Google tracking me and what am I doing wrong

Misuse of free accounts for spamming and similar is a big problem many providers face. Thus they try to detect early if an account creation is somehow unusual, like being automated by a computer or multiple accounts created by cheap labor.

By using a fresh browser profile and trying to be as undedectable as possible you are essentially behaving similar to how massive account creation by cheap labor is done. And you are behaving contrary to the common user for which google usually has lot of data, like interaction with the search engine, google analytics, ads etc. These collected data can be used to decide if the behavior seen in account creation looks like a typical innocent user or more like somebody who wants to create yet another new account, maybe for spamming or selling. And while Google cannot be fully sure of the intentions of the user they can at least add another verification step if they notice unusual behavior - and that is what you get.

In short: the problem is not that Google is tracking you and thus knows that you are the same user who just created an account. The problem is instead that Google has not enough tracking data to be sure that you are an innocent user.

Disclaimer: I don't know if this is really done this way. But, given the amount of information Google has about different user behavior, the advances they make  in distinguishing between usual and unusual behavior which they use for example to improve use of captchas or decide that they don't need one and the massive use of big data I just expect them to use all this to minimize account misuse.


Should I include a random padding in every HTTPS request and response? According to the following paper, it is possible to decrypt HTTPS traffic by inspecting AJAX calls and using the size parameter as a cryptographic oracle.

Should I be sending a variable length payload alongside every HTTPS GET or POST?  Is that sufficient in protecting myself from this attack?

Should the HTTPS response have a variable length string appended as well?

How large should that random appendage of random length data be?

From the outside, one can only see the length of the exchanged data, i.e. the total length of the request, and the total length of the response (rounded to a multiple of the symmetric cipher block size, e.g. 16 bytes if AES is used; but not rounded at all with RC4). To avoid leaking any information, all requests and all responses should have exactly the same size; so the padding should have a variable size which depends on the length of the padded data. If you add padding with a random length but with a probability distribution which does not depend on the size of the padded request or response, then the original request length can be reconstructed statistically if that request is performed on a regular basis.

There is no need for the padding bytes to be random. Only the length is visible "from the outside". You can use constant byte values (e.g. a custom HTTP header X-Padding: ZZZZZZZZZ with, as contents, a sequence of 'Z' of appropriate length). Using random data could actually leak extra information through timing (if the random generator is not very fast, the attacker could observe the client or server reaction time and deduce the size of the padding, thus indirectly obtaining the true request or response length).

Always targeting a fixed size is wasteful of network bandwidth, because all requests will have the size of the largest possible request, and all responses the size of the largest possible response. @Paŭlo's suggestion of padding up to the next multiple of a given value (e.g. up to the next length which is a multiple of 500 bytes) is appropriate: it leaks a bit more than always padding to the same length, but it does not leak much; and it avoids wasting network resources.


Are these SSH passwords of hacked servers? I have been seeing persistent SSH connection attempts on my computer from a familiar IP address. I got curious and decided to do some Googling on the IP address. Turns out that someone from Indonesia is publicly sharing a whole list of IP addresses of servers, some from Digital Ocean, with their SSH passwords. I am not sure whether these servers belong to that person, whether these are admin passwords and what is the purpose of the person sharing it publicly. But it does look shady since I am getting SSH login attempts from one of those IPs. Are these SSH passwords of hacked servers? Why is the person sharing it? What can be done about it?

I'm seeing the posted link and it seems to be an Indonesian facebook page, where the group writes IPs and credentials of different servers. I think so these servers don't belong to the group, but the group itself discovers them by sharing their credentials. I don't know what they do with them, but then the servers are most likely hacked for some purpose.
Similar attacks are performed by brute forcing an SSH connection through specific tool (Hydra, Medusa, ...), as you are seeing in your computer. So, it is very important to have a strong SSH password (alphanumerics>=10), to define a specific user for the SSH connection, and to disable the root/admin account for SSH logins. You can find a lot of posts on how to protect a SSH server:

http://www.tecmint.com/5-best-practices-to-secure-and-protect-ssh-server/

Unfortunately it's common to find out similar group of crackers (pay attention, not hacker), but it's the first time I see a clear fb page.


Should I be concerned with fake accounts registered on my website? I own a website ( Ostetso ) that is targeted at iOS app developers.  We provide cloud services for developers who want to add a social network into their apps.  On the website, users can download our SDK and register for our service.  Over the past week or so I have noticed about three or four registrations a day coming in from users with email addresses at the same 163.com domain.  The email addresses look as if they are bot generated and these registrations all seem to me to be fake accounts.

I can't think of any reason why someone would want or need to create fake accounts with us.  Does anyone here have opinions on that?   Is this something I should be concerned about?

Thank you!

I can't think of any reason why someone would want or need to create fake accounts with us.

I think the basic answer to that is that someone will, and at least part of the reason might be because they can.

Your SDK page mentions that you send an email to the address provided to confirm account details, which presumably means the batch of addresses you are concerned about have been verified (i.e. before actually creating the account, you have ensured the address used for registration is owned by the entity making the registration).

In which case, short of generic things like monitoring account resource usage and general activity, there isn't really a lot it seems you can do.
The registrations followed the same flow as a genuine user would.

If you have a concern about these accounts, then I guess it you could consider banning/disabling them and seeing if the users get in touch (or heavily limit their account quotas).

I don't know, though, if 3/4 registrations a day for something like this from a domain like 163.com (or gmail.com, for that matter) is hugely significant - or whether it might be people hearing about your site.
Even over a couple of weeks, that's under 60 accounts, and it might be a short spike.

But do consider having a plan to identify accounts that abuse your service, and a mechanism for dealing with them.


Using PGP in emails - is there to find the key? Suppose both the receiver and sender use PGP. Suppose someone send from the sender an email and sent it to the receiver. Now he gets the content of the email at the receiver. Can he know now the keys and decrypt the past and future emails. Can he extract from this process the keys?

Your question is not very clear, but in public-key cryptography,
everyone has a public key which can be freely distributed, and a
secret key which only that person knows.

To send a secret message to someone, you encrypt it with their public
key. It can only be decrypted with the secret key.

To sign a message, you use your secret key. No one else can sign it with
that key, but anyone can verify the signature using your public key.

Does that clear things up?


Will htmlspecialchars (php) be enough for making secure PDF files with user entered data? My app creates an PDF file and uses an user entered info. How can I avoid all attacks with PDF vector?

Will htmlspecialchars be enough?

I don't want to enable JavaScript in PDF.

How are you generating your PDFs? Unless you are creating HTML markup and using a tool to convert that to PDF, htmlspecialchars won't be of any use to you. < and & are not special in PDF text content.

If you are using the PHP PDFlib functions like PDF_add_table_cell to put your text in the document, there is no need for any particular kind of escaping. Those functions take raw text without any characters being 'special'. Other than general-purpose input filtering to remove unwanted control characters, no string preparation steps should be necessary.

I'm not sure what attacks you're trying to avoid; the most common problem with PDF is embedded scripting malware, but unless you're deliberately putting script in (using eg PDF_create_action) there won't be any in your produced document.

There was a global-XSS vulnerability in the browser PDF plugin once that affected any site hosting a PDF; if you want to ensure protection from that for users with old plugins you can serve all your PDFs with Content-Disposition: attachment.