LSP.net is a specialized provider of business solutions and quality management for the language industry.
Friday, July 13, 2012
Customer and resource log-in for your web site
You might want your customers to log in to their OTM service pages directly from your web site. Here's the HTML code:
Here is how it works with the resources' log-in:
Please replace subdomain with your OTM subdomain.
Labels:
OTM Features,
OTM Workflow
Monday, June 25, 2012
OTM <––> SDL Trados
As of the fourth quarter of this year, OTM will actively support project work with SDL Trados Studio.
LSP.net is currently developing a software module (middleware) which is installed on a user’s workstation and makes use of the interfaces for OTM and SDL Trados. The data connection to OTM are certified and securely encrypted.
The Trados analysis logs (together with the project packages) will be sent back to OTM via the middleware. Configurable weighting values for evaluating the log data are stored in OTM.
With just a few clicks, the project manager can convert the data from the analysis to corresponding quotation items in OTM. Various formats can be selected for the quotation.
The process for creating a job in OTM to pass the data on to the translator is similarly convenient.
The new software module simplifies working with Trados projects considerably and will be available by the end of the year through the SDL Open Exchange or directly from LSP.net. The price of the module has not yet been determined.
OTM® is a registered trademark of LSP.net
SDL TRADOS® is a registered trademark of SDL
Labels:
OTM Features,
Press Release
Saturday, June 16, 2012
Major improvements in OTM security
Up to now, passwords in OTM have been stored in the database with encryption corresponding to the usual Internet standard, a cryptographic hash function similar to the MD5 message-digest algorithm. As a consequence, even if an intruder manages to access the list of passwords, these cannot be used. Hash codes require considerable can be effort to break – as long as the password is “secure”. A password like “amadeus” is not secure, because it can be decrypted easily using a dictionary attack. (“Dictionary” in this context refers to a list of previously identified passwords.) So in this case, security really does depend on the user.
We have changed this procedure for two reasons. First of all, it is important to minimize the dependence on the user. In other words, an encrypted password stored in the database should remain “unbreakable” even if it is not secure (such as in the case of “amadeus” mentioned above). Secondly, the rapid development of greater technical capacities by hackers - using specialized hardware, Cloud computing and improved methods - is a source of increasingly deep concern. The dictionaries available for such attacks are also constantly increasing in size and now comprise billions of compromised passwords. Thus even passwords previously considered secure, such as “Iwab033yrsB4” are no longer sufficient for higher standards of security.
The technical reason for this, to put it simply, is that the code generated during hash encryption (the “hash”) is too short. It comprises a mere 16 hexadecimal characters. Such code might look like this: 3dd891646eab094f. One character can assume 16 different values (0,1,2,3,4,5,6,7,8,9,a,b,c,d,e,f). This results in 18,446,744,073,709,551,616 possible codes. That sounds like a lot, but it’s not enough to defend against high-powered computers and dictionary attacks. Though not all hashes and their associated passwords can be stored in a dictionary, because this would make it quite enormous, but if a password is listed in a dictionary, it can be compromised in seconds, enabling the attacker to log into the system. There is an underlying issue to cause even greater concern: this huge number of possible hash codes is actually not a problem any more for specialized hardware or networks of computers today. According to the latest estimates, a brute force attack on a specific password (meaning the rote, systematic attempt of all possible combinations until the password is “cracked”) would take about four days with the right equipment. This is completely unacceptable, of course. The security of encryption methods rests largely on the fact that guessing takes too much time for an attacker. The used algorithm is simply too efficient. Calculating the hash value does not take long enough.
Therefore, we have improved OTM security on three levels:
- The length of the hash code stored was increased to block dictionary attacks.
- Password security no longer depends exclusively on the user’s entry.
- A more cumbersome cryptographic method is now used to cause delays to make brute force attacks ineffective.
>> The change poses no problem for OTM users, as there is no compulsion to create new passwords.
Our method comprises the following: First, the password entered by the user is recoded to the previous hash value by the old method. This hash is then extended with a secret, long character string (referred to as salt). Then this extended character string is encrypted with the SHA256 method and compared with the entry (already converted by us) in the database. If the comparison shows a match, the password entered was correct. Otherwise not.
Thus the user can continue to work with the old password, because we can already convert its old hash value to the new value in the database even if the actual text of the password is not known. The salt makes the database hash value independent of the complexity of the user’s entry. Altogether, the method slows the process quite a lot, though not in a way noticeable by the user, because it is only a matter of milliseconds. But for an attacker, this difference makes a brute force attack pointless. Instead of taking days to break a password, the thousands of billions of iterations required would add a century or so to the time needed for a successful attack. Moreover, the hash value saved is no longer a mere 16 characters, each with 16 possible values, but rather 64 characters with 16 values. This translates to 1.1579208923731619542357098500869e+77 possible values for the hash code. No dictionary attack can cope with numbers of that magnitude. Thus all three points of possible attack have been reinforced, dramatically improving password security.
The changes will take effect with the OTM version 5.6.5 update.
-----------------------------
For more information on the above topics, please click the following links:
MD5: http://en.wikipedia.org/wiki/MD5
Salt: http://en.wikipedia.org/wiki/Salt_%28cryptography%29
SHA256: http://en.wikipedia.org/wiki/SHA256
Dictionary attack: http://en.wikipedia.org/wiki/Dictionary_attack
Labels:
OTM changelog,
OTM Features,
Security
Wednesday, May 23, 2012
Customer communication – now in French!
One of the great strengths of the Online Translation Manager (OTM) is the adaptability of its interface to communicate with clients in local markets. As increasing numbers of language service providers and corporations have adopted OTM as their platform for secure project management, job handling and delivery, the modules for correspondence and the confidential client portal have been localized in a number of languages: English, German, Spanish, Catalan, Dutch, Portuguese and Finnish. Now LSP.net partner FILOGIS TRADUCTION has added French to the client interface.
Standard correspondence templates for quotations and invoicing, project schedules and notifications as well as deliveries will improve the ease of communication with your French clientele, who can also access their deliveries and project-related documents conveniently in their native language. As with all important communication modules in OTM, the templates can also be adapted to suit your individual style preferences.
Localized communication is merely one aspect of the OTM philosophy of best practice, with reliable infrastructure, confidentiality and legal security foremost in its design. For more information on the benefits of this platform for language service management, see the information page for the Online Translation Manager.
Labels:
OTM changelog,
OTM Features
Tuesday, May 1, 2012
OTM Feature: Job description templates
The new OTM feature "Job description templates" is very helpful if you manage projects with complex or numerous jobs.
In a project with numerous target languages, you can copy one job description text to all other jobs with just one click.
Any job description text can be saved as a template. Templates can be edited or deleted.
If you need a certain template, you can load it from the repository. Load a text from your stored templates or templates from co-workers in your company.
Labels:
OTM changelog,
OTM Features,
OTM Workflow
Sunday, April 15, 2012
_changelog OTM Update 5.6 – 2012-04-12
The project manager or administrator can generate a certificate in OTM to attest to the quality and correctness of a translation. The issuer of the certificate is the respective agency. The recipient of the certificate is the particular end customer.
The certificate text can be edited and can be changed under >Administration >Standard texts >Documents (PDF) below the invoices section.
Files for which certificates are required must be marked in the project's file repository:
Generating the certificate is optional and only possible if the relevant project has at least one line item with a translation service. Only one certificate can be issued per project. In case of an error, a certificate can be re-issued.
The certificate for translations in a project is generated as a separate PDF document and saved in the project’s document repository. A certificate can be previewed before it is generated.
The certificate is produced at the same time as the final invoice if the option to create the certificate is checked. The certificate and invoice are generated as two separate documents and sent as two different e-mail attachments as required.
A standard e-mail text from >Administration >Standard texts >E-mails is used automatically if a certificate is created together with the invoice and the option to send by e-mail is marked.
The certificate will be printed on the agency’s letterhead.
Editable text sections
1. Certificate subject line2. Certificate body text
Placeholders in the body text:
- the project number [% PROJECT_NUMBER %],
- the project description [% PROJECT_NAME %] (if there is one),
- the file names of translated file(s): [% PROJECT_CERTFILES %],
- the source and target language(s) [% PROJECT_LANGUAGES %]
Certificates can have two signatures
As a custom tag for signatures, you can usea) both custom tags [% SIGNATURE_PM %] and [% SIGNATURE_SECOND %] together or individually or b) the combined tag [% BOTH_SIGNATURES_SIDEBYSIDE %].
New menu item
The signature files (file format: PNG or JPG) can be uploaded to OTM at >Administration >Corporate Identity >Signature files. The image is scaled automatically to a standard size and can be used at the desired position by setting a placeholder in the document. You can define whether the certificate should always bear the signature of a particular person (such as the managing director) or the signature of the respective project manager, or both.The certificate is associated unambiguously with the project via the file name and can be downloaded from the project documents.
Labels:
DIN EN 15038,
OTM changelog,
OTM Features,
OTM Workflow
Subscribe to:
Posts (Atom)