Leaderboard

If you follow us on Twitter, you must be aware that since yesterday we have been warning Mac and Linux users of the Tor anonymity browser about a critical vulnerability that could leak their real IP addresses to potential attackers when they visit certain types of web pages. Discovered by Italian security researcher Filippo Cavallarin, the vulnerability resides in FireFox that eventually also affects Tor Browser, since the privacy-aware service that allows users to surf the web anonymously uses FireFox at its core. Dubbed by the researcher as TorMoil, the vulnerability affects Tor browser for macOS and Linux and not for Windows, but keeping in mind the security and privacy of Tor users, details about this flaw has not been yet publicly revealed. Cavallarin, CEO of the security firm We Are Segment, privately reported the security vulnerability to Tor developers on Thursday (October 26), and the Tor developers have rolled out an emergency update Tor version 7.0.8. According to a short blog post published Tuesday by We Are Segment, the TorMoil vulnerability is due to a Firefox issue in "handling file:// URLs." TorMoil is triggered when users click on links that begin with file:// addresses, instead of the more common https:// and http:// addresses. "Once an affected user [running macOS or Linux system] navigates to a specially crafted web page, the operating system may directly connect to the remote host, bypassing Tor Browser." he Tor Project has currently issued a temporary workaround to prevent the real IP leakage. So, macOS and Linux users may found the updated versions of the Tor anonymity browser not behaving properly while navigating to file:// addresses, until a permanent patch becomes available. "Opening those in a new tab or new window does not work either. A workaround for those issues is dragging the link into the URL bar or on a tab instead. We track this follow-up regression in bug 24136." According to the Tor Project, users of both the Windows versions of Tor, Tails and the sandboxed-tor-browser that's in alpha testing are not affected. The Tor Project also said there's no evidence the TorMoil vulnerability has been actively exploited by hackers to obtain the IP addresses of Tor users. However, lack of evidence does not prove the bug was not exploited by nation-state attackers and skilled hackers, given the high-demand of Tor zero-day exploit in the market, where Zerodium is ready to pay anyone $1 Million for its exploit. In an attempt to keep its users' privacy protected, the Tor Project has recently announced the release of Tor 0.3.2.1-alpha that includes support for the next generation onion services, with the integration of new cutting-edge encryption and improvement of overall authentication into its web service. Via thehackernews.com

SRI-UL MAAAAAAAA fugi repede ca vine garda si te baga la parnaie. sa strangi tare din buci, btw

I can actually look up how long I have by logging into my Coinbase account, looking at the history of the Bitcoin wallet, and seeing this transaction I got back in 2012 after signing up for Coinbase. Bitcoin was trading at about $6.50 per. If I still had that 0.1 BTC, that’d be worth over $500 at the time of this writing. In case people are wondering, I ended up selling that when a Bitcoin was worth $2000. So I only made $200 out of it rather than the $550 now. Should have held on. Thank you Brian. Despite knowing about Bitcoin’s existence, I never got much involved. I saw the rises and falls of the $/BTC ratio. I’ve seen people talk about how much of the future it is, and seen a few articles about how pointless BTC is. I never had an opinion on that, only somewhat followed along. Similarly, I have barely followed blockchains themselves. Recently, my dad has brought up multiple times how the CNBC and Bloomberg stations he watches in the mornings bring up blockchains often, and he doesn’t know what it means at all. And then suddenly, I figured I should try to learn about the blockchain more than the top level information I had. I started by doing a lot of “research”, which means I would search all around the internet trying to find other articles explaining the blockchain. Some were good, some were bad, some were dense, some were super upper level. Reading only goes so far, and if there’s one thing I know, it’s that reading to learn doesn’t get you even close to the knowledge you get from programming to learn. So I figured I should go through and try to write my own basic local blockchain. A big thing to mention here is that there are differences in a basic blockchain like I’m describing here and a ‘professional’ blockchain. This chain will not create a crypto currency. Blockchains do not require producing coins that can be traded and exchanged for physical money. Blockchains are used to store and verify information. Coins help incentive nodes to participate in validation but don’t need to exist. The reason I’m writing this post is 1) so people reading this can learn more about blockchains themselves, and 2) so I can try to learn more by explaining the code and not just writing it. In this post, I’ll show the way I want to store the blockchain data and generate an initial block, how a node can sync up with the local blockchain data, how to display the blockchain (which will be used in the future to sync with other nodes), and then how to go through and mine and create valid new blocks. For this first post, there are no other nodes. There are no wallets, no peers, no important data. Information on those will come later. Other Posts in This Series Part 2 — Syncing Chains From Different Nodes Part 3 — Nodes that Mine TL;DR If you don’t want to get into specifics and read the code, or if you came across this post while searching for an article that describes blockchains understandably, I’ll attempt to write a summary about how a blockchains work. At a super high level, a blockchain is a database where everyone participating in the blockchain is able to store, view, confirm, and never delete the data. On a somewhat lower level, the data in these blocks can be anything as long as that specific blockchain allows it. For example, the data in the Bitcoin blockchain is only transactions of Bitcoins between accounts. The Ethereum blockchain allows similar transactions of Ether’s, but also transactions that are used to run code. Slightly more downward, before a block is created and linked into the blockchain, it is validated by a majority of people working on the blockchain, referred to as nodes. The true blockchain is the chain containing the greatest number of blocks that is correctly verified by the majority of the nodes. That means if a node attempts to change the data in a previous block, the newer blocks will not be valid and nodes will not trust the data from the incorrect block. Don’t worry if this is all confusing. It took me a while to figure that out myself and a much longer time to be able to write this in a way that my sister (who has no background in anything blockchain) understands. If you want to look at the code, check out the part 1 branch on Github. Anyone with questions, comments, corrections, or praise (if you feel like being super nice!), get in contact, or let me know on twitter. Step 1 — Classes and Files Step 1 for me is to write a class that handles the blocks when a node is running. I’ll call this class Block. Frankly, there isn’t much to do with this class. In the __init__ function, we’re going to trust that all the required information is provided in a dictionary. If I were writing a production blockchain, this wouldn’t be smart, but it’s fine for the example where I’m the only one writing all the code. I also want to write a method that spits out the important block information into a dict, and then have a nicer way to show block information if I print a block to the terminal. class Block(object): def __init__(self, dictionary): ''' We're looking for index, timestamp, data, prev_hash, nonce ''' for k, v in dictionary.items(): setattr(self, k, v) if not hasattr(self, 'hash'): #in creating the first block, needs to be removed in future self.hash = self.create_self_hash() def __dict__(self): info = {} info['index'] = str(self.index) info['timestamp'] = str(self.timestamp) info['prev_hash'] = str(self.prev_hash) info['hash'] = str(self.hash) info['data'] = str(self.data) return info def __str__(self): return "Block<prev_hash: %s,hash: %s>" % (self.prev_hash, self.hash) When we’re looking to create a first block, we can run the simple code. def create_first_block(): # index zero and arbitrary previous hash block_data = {} block_data['index'] = 0 block_data['timestamp'] = date.datetime.now() block_data['data'] = 'First block data' block_data['prev_hash'] = None block = Block(block_data) return block Nice. The final question of this section is where to store the data in the file system. We want this so we don’t lose our local block data if we turn off the node. In an attempt to somewhat copy the Etherium Mist folder scheme, I’m going to name the folder with the data ‘chaindata’. Each block will be allowed its own file for now where it’s named based on its index. We need to make sure that the filename begins with plenty of leading zeros so the blocks are in numerical order. With the code above, this is what I need to create the first block. #check if chaindata folder exists. chaindata_dir = 'chaindata' if not os.path.exists(chaindata_dir): #make chaindata dir os.mkdir(chaindata_dir) #check if dir is empty from just creation, or empty before if os.listdir(chaindata_dir) == []: #create first block first_block = create_first_block() first_block.self_save() Step 2 — Syncing the blockchain, locally When you start a node, before you’re able to start mining, interpreting the data, or send / create new data for the chain, you need to sync the node. Since there are no other nodes, I’m only talking about reading the blocks from the local files. In the future, reading from files will be part of syncing, but also talking to peers to gather the blocks that were generated while you weren’t running your own node. def sync(): node_blocks = [] #We're assuming that the folder and at least initial block exists chaindata_dir = 'chaindata' if os.path.exists(chaindata_dir): for filename in os.listdir(chaindata_dir): if filename.endswith('.json'): #.DS_Store sometimes screws things up filepath = '%s/%s' % (chaindata_dir, filename) with open(filepath, 'r') as block_file: block_info = json.load(block_file) block_object = Block(block_info) #since we can init a Block object with just a dict node_blocks.append(block_object) return node_blocks Nice and simple, for now. Reading strings from a folder and loading them into data structures doesn’t require super complicated code. For now this works. But in future posts when I write the ability for different nodes to communicate, this sync function is going to get a lot more complicated. Step 3 — Displaying the blockchain Now that we have the blockchain in memory, I want to start being able to show the chain in a browser. Two reasons for doing this now. First is to validate in a browser that things have changed. And then also I’ll want to use the browser in the future to view and act on the blockchain. Like sending transactions or managing wallets. I use Flask here since it’s impressively easy to start, and also since I’m in control. Here’s the code to show the blockchain json. I’ll ignore the import requirements to save space here. node = Flask(__name__) node_blocks = sync.sync() #inital blocks that are synced @node.route('/blockchain.json', methods=['GET']) def blockchain(): ''' Shoots back the blockchain, which in our case, is a json list of hashes with the block information which is: index timestamp data hash prev_hash ''' node_blocks = sync.sync() #regrab the nodes if they've changed # Convert our blocks into dictionaries # so we can send them as json objects later python_blocks = [] for block in node_blocks: python_blocks.append(block.__dict__()) json_blocks = json.dumps(python_blocks) return json_blocks if __name__ == '__main__': node.run() Run this code, visit localhost:3000/blockchain.json, and you’ll see the current blocks spit out. Part 4 — “Mining”, also known as block creation We only have that one genesis block, and if we have more data we want to store and distribute, we need a way to include that into a new block. The question is how to create a new block while linking back to a previous one. In the Bitcoin whitepaper, Satoshi describes it as the following. Note that ‘timestamp server’ is referred to as a ‘node’: The solution we propose begins with a timestamp server. A timestamp server works by taking a hash of a block of items to be timestamped and widely publishing the hash... The timestamp proves that the data must have existed at the time, obviously, in order to get into the hash. Each timestamp includes the previous timestamp in its hash, forming a chain, with each additional timestamp reinforcing the ones before it. Here’s a screenshot of the picture below the description. A summary of that section is that in order to link the blocks together, we create a hash of the information of a new block that includes the time of block creation, the hash of the previous block, and the information in the block. I’ll refer to this group of information as the block’s ‘header’. In this way, we’re able to verify a block’s truthfulness by running through all the hashes before a block and validating the sequence. For my header the case here the header I’m creating is adding the string values together into a giant string. The data I’m including is: Index, meaning which number of block this will be Previous block’s hash the data, in this case is just random strings. For bitcoin, this is referred to as the Merkle root, which is info about the transactions The timestamp of when we’re mining the block def generate_header(index, prev_hash, data, timestamp): return str(index) + prev_hash + data + str(timestamp) Before getting confused, adding the strings of information together isn’t required to create a header. The requirement is that everyone knows how to generate a block’s header, and within the header is the previous block’s hash. This is so everyone can confirm the correct hash for the new block, and validate the link between the two blocks. The Bitcoin header is much more complex than combining strings. It uses hashes of data, times, and deals with how the bytes are stored in computer memory. But for now, adding strings suffices. Once we have the header, we want to go through and calculate the validated hash, and by calculating the hash. In my hash calculation, I’m going to be doing something slightly different than Bitcoin’s method, but I’m still running the block header through the sha256 function. def calculate_hash(index, prev_hash, data, timestamp, nonce): header_string = generate_header(index, prev_hash, data, timestamp, nonce) sha = hashlib.sha256() sha.update(header_string) return sha.hexdigest() Finally, to mine the block we use the functions above to get a hash for the new block, store the hash in the new block, and then save that block to the chaindata directory. node_blocks = sync.sync() def mine(last_block): index = int(last_block.index) + 1 timestamp = date.datetime.now() data = "I block #%s" % (int(last_block.index) + 1) #random string for now, not transactions prev_hash = last_block.hash block_hash = calculate_hash(index, prev_hash, data, timestamp) block_data = {} block_data['index'] = int(last_block.index) + 1 block_data['timestamp'] = date.datetime.now() block_data['data'] = "I block #%s" % last_block.index block_data['prev_hash'] = last_block.hash block_data['hash'] = block_hash return Block(block_data) def save_block(block): chaindata_dir = 'chaindata' filename = '%s/%s.json' % (chaindata_dir, block.index) with open(filename, 'w') as block_file: print new_block.__dict__() json.dump(block.__dict__(), block_file) if __name__ == '__main__': last_block = node_blocks[-1] new_block = mine(last_block) save_block(new_block) Tada! Though with this type of block creation, whoever has the fastest CPU is able to create a chain that’s the longest which other nodes would conceive as true. We need some way to slow down block creation and confirm each other before moving towards the next block. Part 5 — Proof-of-Work In order to do the slowdown, I’m throwing in Proof-of-Work as Bitcoin does. Proof-of-Stake is another way you’ll see blockchains use to get consensus, but for this I’ll go with work. The way to do this is to adjust the requirement that a block’s hash has certain properties. Like bitcoin, I’m going to make sure that the hash begins with a certain number of zeros before you can move on to the next one. The way to do this is to throw on one more piece of information into the header — a nonce. def generate_header(index, prev_hash, data, timestamp, nonce): return str(index) + prev_hash + data + str(timestamp) + str(nonce) Now the mining function is adjusted to create the hash, but if the block’s hash doesn’t lead with enough zeros, we increment the nonce value, create the new header, calculate the new hash and check to see if that leads with enough zeros. NUM_ZEROS = 4 def mine(last_block): index = int(last_block.index) + 1 timestamp = date.datetime.now() data = "I block #%s" % (int(last_block.index) + 1) #random string for now, not transactions prev_hash = last_block.hash nonce = 0 block_hash = calculate_hash(index, prev_hash, data, timestamp, nonce) while str(block_hash[0:NUM_ZEROS]) != '0' * NUM_ZEROS: nonce += 1 block_hash = calculate_hash(index, prev_hash, data, timestamp, nonce) block_data = {} block_data['index'] = int(last_block.index) + 1 block_data['timestamp'] = date.datetime.now() block_data['data'] = "I block #%s" % last_block.index block_data['prev_hash'] = last_block.hash block_data['hash'] = block_hash block_data['nonce'] = nonce return Block(block_data) Excellent. This new block contains the valid nonce value so other nodes can validate the hash. We can generate, save, and distribute this new block to the rest. Summary And that’s it! For now. There are tons of questions and features for this blockchain that I haven’t included. For example, how do other nodes become involved? How would nodes transfer data that they want included in a block? How do we store the information in the block other than just a giant string Is there a better type of header that doesn’t include that giant data string? There will be more parts of the series coming where I’ll move forward with solving these questions. So if you have suggestions of what parts you want to see, let me know on twitter, comment on this post, or get in contact! Thanks to my sister Sara for reading through this for edits, and asking questions about blockchains so I had to rewrite to clarify. Sursa: https://bigishdata.com/2017/10/17/write-your-own-blockchain-part-1-creating-storing-syncing-displaying-mining-and-proving-work/ part 2: https://bigishdata.com/2017/10/27/build-your-own-blockchain-part-2-syncing-chains-from-different-nodes/ part 3: https://bigishdata.com/2017/11/02/build-your-own-blockchain-part-3-writing-nodes-that-mine/

Cred ca nu. Am vazut ca facebook dezvolta clasification Neural Networks pentru securitate (anti bots + anti hack), la un nivel similar cu google captcha. Vin vremuri grele pt gainarii de promovare pe facebook/seo.

Macar a rascolit amintiri baiatul De cand era categoria Show-Off activa //edit sterge-ti contul de youtube rapid daca vrei sa petreci sarbatorile in liniste ai niste fapte foarte foarte grave cu care te lauzi degeaba faci parnaie/scoala de corectie de o sa-ti fie frica sa mai scrii o linie de cod . Pentru varsta ta esti la un nivel ok si stii destule.

Ai aici ceva interesant despre criptografie, incepe cu Caesar Cipher si termina cu RSA. https://www.khanacademy.org/computing/computer-science/cryptography

http://constantdullaart.com/TOS/ si http://therevolvinginternet.com/

Cel mai simplu algoritm de criptare si probabil si cel mai potrivit pentru prietenul tau este inlocuirea unui caracter N cu valoarea lui in ASCII N+x. Sa zicem ca ai cuvantul CAT, iar cheia ta va fi 2. Fiecare dintre litere va fi inlocuita cu valoarea sa in ASCII + 2. Deci CAT devine: ECV. C=67, 67+2=69 (E) samd. ASCII Table

Ai aici cateva informatii de baza despre crypto: Encryption vs. Encoding vs. Hashing These are three terms that are commonly mixed. They are not interchangeable and they refer to different things. Encoding is the process of transforming data from one format into another. Converting from Hex to Binary is encoding. The only thing required to read data or to change it into whatever arbitrary format you desire is the encoding scheme. This is a public bit of data that explains how a particular encoding works (e.g. Base64). Encryption is the process of transforming data with the purpose of keeping it secret. This means that the encrypted value will disclose little information about the original data. This process requires an algorithm that can be publicly known and an encryption key that should be kept secret. Hashing is essentially a signature of an arbitrary piece of data. It is a one-way function that cannot be reversed nor can the original information be gleaned from the hash value. ---------------------------------------------------------------------------------------------------------------------------------------------------------------- Symmetric and Asymmetric Encryption Symmetric encryption uses the same key to encrypt and decrypt - e.g. DES, 3DES, AES, etc. Asymmetric encryption uses a key pair - one for encryption, one for decryption - e.g. RSA. ---------------------------------------------------------------------------------------------------------------------------------------------------------------- Encryption Algorithms DES symmetric 64-bit block 56-bit key + 8 parity bits considered insecure 3DES symmetric 64-bit block uses 3,2, or 1 keys 3TDEA- Ek1(Dk2(Ek3())) 2TDEA - Ek1(Dk2(Ek1())) 1TDEA - effectively DES - Ek1(Dk1(Ek1())) AES symmetric 128-bit block 128, 192, or 256-bit key AES is a standard based on the Rijndael cipher. RSA asymmetric 64/128-bit block Keys should be 2048+ bits RSA was never meant to encrypt large amounts of data, so it is not entirely correct to say it is a block cipher. RC4 symmetric stream 40-2048 bits considered insecure Many other encryption algorithms exist. These are just the most common. ---------------------------------------------------------------------------------------------------------------------------------------------------------------- Hashing Algorithms MD5 128-bit hash considered obsolete. collisions have been identified SHA-1 160-bit (20 byte) hash phasing out. collisions have been identified Recommendation is to either use pair of hashing algorithms, or to use SHA-256 or SHA-512. MD5, SHA-1/256/512 operate on 512-bit blocks. ----------------------------------------------------------------------------------------------------------------------------------------------------------------

http://security.cs.pub.ro/hexcellents/wiki/kb/crypto/home

Race The Web (RTW) Tests for race conditions in web applications by sending out a user-specified number of requests to a target URL (or URLs) simultaneously, and then compares the responses from the server for uniqueness. Includes a number of configuration options. UPDATE: Now CI Compatible! Version 2.0.0 now makes it easier than ever to integrate RTW into your continuous integration pipeline (à la Jenkins, Travis, or Drone), through the use of an easy to use HTTP API. More information can be found in the Usage section below. Watch The Talk Racing the Web - Hackfest 2016 Usage With configuration file $ race-the-web config.toml API $ race-the-web Sursa: https://github.com/insp3ctre/race-the-web

Lab for Java Deserialization Vulnerabilities This content is related to the paper written for the 12th edition of H2HC magazine. See full paper in: https://www.h2hc.com.br/revista/ Slides and video of the talk will be available soon. Um overview sobre as bases das falhas de desserialização nativa em ambientes Java (JVM) An overview of deserialization vulnerabilities in the Java Virtual Machine (JVM) Content The lab contains code samples that help you understand deserialization vulnerabilities and how gadget chains exploit them. The goal is to provide a better understanding so that you can develop new payloads and/or better design your environments. There is also a vulnerable testing application (VulnerableHTTPServer.java), which helps you test your payloads. Sursa: https://github.com/joaomatosf/JavaDeserH2HC

Scriu acest ghid pentru cei care vor dori in viitor ca cineva (individ/grup/companie) sa le faca un website si sper sa le fie util atat lor: pentru a isi da seama ce vor, pentru a reduce riscul de a fi tepuiti, etc. cat si companiei: sa inteleaga contextul, asteptarile, ce trebuie sa livreze, etc. Insa si pentru sunt satul de cei care asteapta ca altii sa le citeasca gandurile. Deci.. inainte de a discuta cu cineva o oferta de pret si alte detalii, ar fi ideal sa asterneti in scris urmatoarele. Evident, se poate adapta dupa nevoi: 1. O foarte scurta introducere: Daca este o firma, cand a luat fiinta, cu ce se ocupa, cati angajati, realizari, etc. Daca este un site personal: detaliile corespunzatoare. Si asa mai departe. Este un site nou sau refacerea unuia existent. 2. Obiectivele: ce vreti sa realizati cu acest website. Se pot imparti eventual pe obiective principale: 3-5 la numar si obiective secundare. Acestea trebuie sa fie realiste. 3. Cui se adreseaza acest site, care ar fi vizitatorul ideal. In functie de obiective, ce fel de vizitator v-ar ajuta sa la atingeti. Ganditi-va la ce ar vrea ei sa faca pe site si la ce ati vrea voi ca ei sa faca pe site si cum acestea pot fi imbinate. Ce vrei sa-i convingi sa faca: sa citeasca ceva, sa urmareasca un clip, sa cumpere ceva, etc. 4. Un schelet al site-ului ideal. Chiar daca acesta va suferi modificari si adaptari dupa consultarea cu cel ce va livra site-ul si chiar daca este cu pixul pe hartie, cum ati vrea sa fie structurat landing page-ul si eventual urmatoarele cateva pagini. Daca folositi un tool de mindmapping (https://bubbl.us/mindmap) veti putea asterne un element grafic extrem de folositor: pentru voi, sa va dati seama de structura potentiala, cat de usor va fi de navigat si sa va asigurati ca nu va scapa nimic din memorie; dar si pentru cei ce lucreaza: sa inteleaga ce vreti sa realizati si sa poata veni cu idei si sugestii. 5. Detaliile tehnice: aceasta lista trebuie sa fie cat mai completa. Unele proiecte mari necesita si luni de zile de lucrat la definirea specificatiilor tehnice. Chiar daca nu le produceti pe toate la inceput, vor fi esentiale pentru cei ce lucreaza sa va poata da un pret estimativ si un timp de livrare. Apoi, inainte de incheierea contractului (un contract nu e neaparat ceva oficial, poate fi contract verbal sau in scris pe Sykpe, etc.) trebuie specificat si confirmat cu exactitate fiecare fiecare detaliu. Un exercitiu recomandat este sa va puneti in pielea vizitatorului si sa navigati mental pe site si sa va ganditi la "user experience" si cum ar putea fi imbunatatit. La urma urmei aceasta este ultima sansa de a adauga cerinte la proiect. Bineinteles ca unii vor fi flexibili insa daca abuzati de bunatatea altora va veti trezi cu neplaceri. De asemenea cine va "mentine" site-ul dupa completare. Este nevoie de un CMS? Sau de training in editarea si updatarea lui? 6. Detalii auxiliare: in afara de cerintele necesare pentru functionarea site-ului, aspecte de design, securitate, viteza, legalitate/compliance, back-ups, integrari, etc. 7. Daca aveti competitie cine este: ce au bun, ce au mai putin bun. Ce puteti folosi ca idee/concept (nu copiat!) si ce puteti imbunatati. Cum ati putea plusa pe slabiciunile lor si cum evitati repetarea greselilor lor? Sunt exemple de site-uri care va plac pe o nisa asemanatoare? Aveti un anume concept in gand? Cat mai multe detalii de genul acesta. 8. Bugetul. Stiu e nasoala treaba cu banii si e greu de multe ori de specificat o suma si mai ales nu vreti din anumite motive sa specificati cati bani aveti alocati pentru asa ceva pentru ca va e frica de faptul ca se va profita de aceasta informatie si intradevar multi o fac si pun preturile in functie de client si de cati bani au. Ca sa evitati aceste lucruri dati niste range-uri cat mai vagi insa realiste si apropiate de realitate ca sa nu va pierdeti nici voi vremea si nici cei cu care luati legatura. Spre exemplu daca aveti un buget de 500 euro puteti spune intre 250 - 800. Daca vi se da un pret de 700, puteti incepe si negocia de la 400 pentru a ajunge apoi la suma dorita insa negocierea este un alt topic de discutie. 9. Deadline-ul. Sa fie cat mai realist, cu obraz insa bine definit. Chestii de genul "cat mai repede", "urgent", etc. sunt penibile. Aici este o oportunitate de a elimina si din riscul pierderii banilor si anume crearea de stagii (milestones): impartiti proiectul pe stagii, si la completarea fiecarei stagiuni cei ce lucreaza vor vedea un procent din suma totala - totul stabilit prin contract. 10. Orice alte detalii, presupuneri, dorinte, chestii de accesibilitate dorite, etc. Bineinteles, in functie de proiect aceste lucruri variaza insa acesta este un punct de plecare pentru: - a nu irosi timpul vostru si al altora - a avea cat mai mari sanse de reusita - a nu fi luati de prosti si tratati (dpdv financiar) ca atare. Succes!

sa echilibram usor balanta un patent "nevinovat" si citeva file dintr-un dosar legat de :"global SIGINT surveillance and collection on analog and digital networks" macar, kaspersky pune la dispozitie codul sursa pentru fi analizat....

The vulnerability It is a known issue that Microsoft NTLM architecture has some failures, hash stealing is not something new, it is one of the first things a pentester tries when attacking a Microsoft environment. But, most of these techniques require user intervention or traffic interception to fulfill the attack. These new attacks require no user interaction, everything is done from the attacker’s side, but of course, there are some conditions that need to be met to be successful with this attack. Link articol: http://www.sysadminjd.com/adv170014-ntlm-sso-exploitation-guide/

https://www.codeproject.com/Articles/44326/MinHook-The-Minimalistic-x-x-API-Hooking-Libra

Numai posturi cu joburi dubioase și spam prin e-mail și sms. Nu e bine. Ban.

Most instant messaging applications are providing enriched link summaries (as shown next with Telegram link previews), including description and a preview image of the website. Depending on the implementation these nice-to-have features could become privacy intrusive: indeed, it might force your client into downloading some remote content from an untrusted third party, hence leaking your IP address and OS version (User-Agent). How does it work? The application (client side or server side) will grab the webpage and look for metadata through the Open Graph protocol. These are simple HTML tags included in the <head> section. Twitter Direct Messages When you share a URL to someone using Twitter DM, the server shall see at least two probes: one request coming from Twitter (AS13414) that will load the URL to get the card and, strangely, a second request coming from a Amazon EC2 server with a random mobile User-Agent. Most likely this is done to check for virus/phishing (Twitter will display a warning upon suspicious links on new messages). Privacy: URL is known to the server, no IP addresses leak (message isn’t E2E encrypted anyway) iMessages Upon sending a link, your mobile device will generate a preview card. All data appear to be processed locally from your device. The receiver will not grab the URL but will have the preview data, meaning either data is cached on Apple server, or data is directly sent to the receiver through the encrypted channel. Privacy: fair WhatsApp WhatsApp will have the same design as iMessage: the sender will generate the link preview (grabbing metadata from the URL) and send this data to the recipient through the server. This will occur even when end-to-end encryption is enabled but it doesn’t seem to violate E2E (URL is grabbed from the client, not the server). Privacy: fair Signal Signal does not have any enriched link preview, neither the client nor server are grabbing the URL. 👍 Privacy: good Telegram The Telegram mobile application will generate the preview server-side. From an app that claims to have E2E this is kind of a big issue. Privacy: URL is known to the server, no IP addresses leak Wire Wire will generate a preview locally (from your mobile device). Interestingly, the Wire web app (on desktop) won’t generate any preview. Worth pointing out you can disable link preview in the application settings, good move. Privacy: fair FB Messenger Facebook servers will grab the URL to display the preview card. Haven’t tested with Secret Conversations. Privacy: URL is known to the server, no IP addresses leak Skype Skype servers will generate the link preview as well. Privacy: URL is known to the server, no IP addresses leak Slack Slack app is generating the link preview server-side. Privacy: URL is known to the server, no IP addresses leak Discord Same thing with discord (tested on Discord web app). Privacy: URL is known to the server, no IP addresses leak Sursa: https://blog.0day.rocks/link-previews-in-im-apps-and-privacy-d32e6056095b

Camera-based, single-step two-factor authentication resilient to pictionary, shoulder surfing attacks A group of researchers from Florida International University and Bloomberg LP have created Pixie, a camera-based two-factor authentication system that could end up being a good alternative to passwords and biometrics-based 2FA options. About Pixie “Pixie authentication is based on what the user has (the trinket) and what the user knows (the particular trinket among all the other objects that the user readily has access to, angle and viewpoint used to register the trinket),” the researchers explained. “Pixie assigns the duty of storing the token for the second factor to a physical object outside the mobile device.” It combines the user’s secret and the second authentication factor, and the authentication is performed in a single step: with snapping a photo of the trinket. The trinket can be any item worn or carried everyday by the user – a watch, shoes, jewelry, shirt patterns, credit cards, logos, a piece of jewelry, a tattoo, and so on. The user doesn’t have to use the whole item as the trinket, just a portion of it (e.g. a section of their shoes, a shirt pattern). “In contrast to biometrics, Pixie enables users to change the authenticating physical factor, as they change accessories they wear or carry. This reduces the risks from an adversary who has acquired the authentication secret from having lifelong consequences for the victims, thereby mitigating the need for biometric traceability and revocation,” the researchers noted. Testing the solution The researchers performed a user study to see whether users would find this solution usable and helpful. Granted, the number of participants was small (42), but it showed that users had less trouble memorizing their trinket than their passwords, and half of them preferred it to passwords. As far as authentication speed, accuracy and resilience to attack are concerned, Pixie definitely looks promising. They implemented Pixie for Android on a HTC One smartphone, and found it processes a login attempt in half a second. The solution also achieves a False Accept Rate of 0.02% and a False Reject Rate of 4.25%, when evaluated over 122,500 authentication instances. “To evaluate the security of Pixie, we introduce several image based attacks, including an image based dictionary (or “pictionary”) attack. Pixie achieves a FAR below 0.09% on such an attack consisting of 14.3 million authentication attempts constructed using public trinket image datasets and images that we collected online,” they shared. “Similar to face based authentication, Pixie is vulnerable to attacks where the adversary captures a picture of the trinket. However, we show that Pixie is resilient to a shoulder surfing attack flavor where the adversary knows or guesses the victim’s trinket object type. Specifically, on a targeted attack dataset of 7,853 images, the average number of ‘trials until success’ exceeds 5,500 irrespective of whether the adversary knows the trinket type or not.” They’ve also developed features that enable the solution to reduce the effectiveness of a “master image” attack. Potential use Pixie can be used both as a standalone authentication solution and as a secondary one. According to the researchers, it could be ideal for remote service authentication through a mobile device scenario, but could also be used for authentication in camera-equipped cyber-physical systems. “For instance, cars can use Pixie to authenticate their drivers locally and to remote services. Pixie can also authenticate users to remote, smart house or child monitoring systems, through their wearable devices. Further, door locks, PIN pads and fingerprint readers can be replaced with a camera through which users snap a photo of their trinket to authenticate,” they noted. “Pixie can be used as an alternative to face based authentication when the users are reluctant to provide their biometric information (e.g. in home game systems where the user needs to authenticate to pick a profile before playing or to unlock certain functionalities). Pixie can also be used as an automatic access control checkpoint (e.g. for accessing privileged parts of a building). The users can print a visual token and use it to pass Pixie access control checkpoints.” There are, of course, authentication scenarios where Pixie would not be a good options, such as authentication in poor light conditions, or a high risk associated with external observers. The researchers have published Pixie (open source) code on GitHub, and an Android app on Google Play. Sursa: https://www.helpnetsecurity.com/2017/10/24/single-step-two-factor-authentication/

As adauga, e bine ca dev, sa foloseasca un tool de management al taskurilor (jira, trelo, asana, etc..) iar clientul poate avea access pentru a putea interveni daca taskurile nu sunt bine intelese/definite dar si pentru a avea o imagine de ansamblu asupra dezvoltarii. Asemenea este esential sa existe un server de dev unde clientul sa poata vedea ultimele implementari. Taskurile trebuie sa ie cat mai granulare, iar daca un task ia mai mult de cateva ore/o zi, poate fi spart in taskuri mai mici, pentru ca asta inseamna ca nu este destul de granular definit. Daca taskurile sunt bine definite, atunci estimarile ies mult mai realiste, caci in procesul de definire a taskurilor iti dai seama daca si ce ti-a scapat initial din estimari. Inca un lucru, niciodata nu se estimeaza un task in timpul ideal de lucru, ci in timpul efectiv. Timp ideal = daca am avea un cronometru unde am cronometra cat am lucra, oprindu-l de fiecare data cand iesim la o tigara sau mergem la toaleta, asta ar fi timpul ideal Timpul efectiv = este timpul ideal, la care se adauga intreruperile, firesti, umane, ca doar nu suntem roboti, si daca nu luam in considerare asta, intotdeauna estimarile noastre o sa fie KO. Si nu trebuie ca dev sa se simta vinovati pt asta, si nici beneficiarii furati, caci este felul in care lucrurile merg, orice altel de estimare va cauza probleme pentru ca nu o sa poata fi respectate termenele si ambii o sa ie nemultumiti. Iar, nu exista un termen batut in cuie, totul este estimativ, ideal este ca totul sa ie cat mai aproape de estimare, totusi la un proiect mare o abatere de 15-20% este rezonabila. Desi o data cu experienta estimarile sunt mai bune iar aceasta poate ajunge si la 1%. Abaterile astea pot veni de la ambele parti, ori clientul s-a apucat sa schimbe anumite lucruri, ori echipa de dezvoltare si-a dat seama ca solutia luata in considerare la estimare nu este cea mai optima. Si este la fel de firesc pe cum este firesc sa exista buguri. Daca nu ai buguri, inseamna ca nu ai testat destul de bine aplicatia si atunci e o problema. Fi la final, un contract strong, trebuie sa stea deasura oricarei discutii.

nu stiu , dar cred ca ma confuzi

Click dreapta Delet

Hello all Get Free VPN For 3 Days!! (Free + Open Port 1194 for hacking PC) go ahead https://www.youtube.com/watch?v=Q6uiO0LrjNU&t=202s