Seguridad, llave y candado. Crédito de imagen: JanBaby, via Pixabay CC0.

Lo que hay que saber sobre las políticas de seguridad

Download PDF

Aprenda a proteger su ordenador personal, su servidor y sus sistemas en la nube con SELinux, la seguridad de Kubernetes y los cortafuegos.

Escrito por Chris Collins y Seth Kenlon, publicado por Open Source Com bajo licencia Creative Commons 4.0; traducción al castellano de Venezuela (es_VE) hecha por Jimmy Olano.

Seguir leyendo

Download PDF
Tiburón limón con varias rémoras adosadas ( https://commons.wikimedia.org/wiki/File:Lemonshark.jpg )

Cómo identificar gente rémora

Download PDF

Con el paso del tiempo me ha tocado trabajar con muchas personas, más de un millar, hombres y mujeres. Aunque nunca estuvieron a mi cargo directo, sí que tuve que darles órdenes explícitas en cuanto a software, hardware y sus usos se refieren, obteniendo los resultados más variopintos que puedan imaginar. No se preocupen: todos los objetivos planteados por las empresas que nos han contratado se han cumplido, lo que acá relato -y me quejo- son los lapsos de tiempo que tardaron en ser logrados. De acuerdo al diccionario deben ser catalogados como rémoras y debemos muy bien saber ser identificar a dichas personas y aislarlas a tiempo.

Seguir leyendo

Download PDF
Logotipo de Google en 2015

Treinta consejos avanzados al buscar en Google y triunfar al intentar

Download PDF

1 Star2 Stars3 Stars4 Stars5 Stars (1 votes, average: 3,00 out of 5)
Cargando…

Página actualizada el sábado 24 de julio de 2021.

Google es una maquinaria poderosa de búsqueda, ignorarla sería como tapar el sol con un dedo.Acá veremos unos consejos útiles a la hora de refinar nuestras búsquedas


Seguir leyendo

Download PDF
Feliz Día del Programador

Feliz Día del Programador 2017

Download PDF

«Feliz Día del Programador» desde el 2015 tenemos conocimiento que celebramos este día, sin distingo del lenguaje que usemos, tengamos que usar o que desarrollemos (los más avezados en la materia). Sin duda que los ordenadores es uno de los más grandes inventos de la humanidad, con la labor destacada de Alan Turing (con quien en vida se cometió una gran injusticia en su vida personal).

Feliz Día del Programador
Feliz Día del Programador

Modestía aparte: sobre nosotros recae un gran poder que conlleva una gran responsabilidad y aprovechamos el día para recordarnos nuestra dosis diaria de humildad, paciencia y empeño no solo en este día sino en todo el año para que los usuarios a quienes nos debemos (y nos dan el sustento económico en este, por ahora, sistema capitalista) sean los máximos beneficiados de nuestros frutos mentales ¡Y SI PROGRAMAMOS EN SOFTWARE LIBRE CONTRIBUIMOS AL PATRIMONIO TECNOLÓGICO DE LA HUMANIDAD! Seguir leyendo

Download PDF

Calculando factoriales de números grandes

Download PDF

El día de ayer por medio del perfil de línea de tiempo del Doctor Juan González observamos el interesante artículo tutorial sobre Python publicado por Juan J. Merelo Guervós el cual incluye retos de programación. Ni tardo ni perezoso, a pesar de llegar cansado a mi hogar, y tras una vigorizante taza de café negro con leche de avena sin azúcar nos dimos a la tarea de practicar algunas cositas para mantener el cerebro en forma y al día con las novedades en programación.

Seguir leyendo

Download PDF
Women and man speaking english.

Inglés conversacional

Download PDF

Aunque este vuestro sitio web no va de ciencias sociales es innegable la influencia -a nuestro pesar- del idioma inglés actualmente. Si antes era el latín la lengua franca del imperio romano, ahora el inglés hace las veces para formar nuevas palabras en castellano -hardware, software – que incluso ya se registran en el diccionario de la Real Academia Española. Es por ello que, para no ser mezquinos, agregamos la siguiente entrada.

Introducción.

Women and man speaking english.
Women and man speaking english.

El idioma inglés es muy simple comparado con el castellano, portugués e italiano -ni hablemos del francés- ya que, por ejemplo, la conjugación de verbos ni se le compara. El caso que nos ocupa hoy es precisamente la parquedad del idioma inglés en el ámbito conversacional. Así como no le gustan los nombres largos -fue duro para ellos tragar completo el de Schwarzenegger– tampoco son de usar muchas palabras en el habla diaria.

La parte que dificulta al idioma inglés para nosotros los castellanohablantes es que cada palabra en ese idioma tiene una pronunciación como palabra completa no por sílabas (que para ellos no existen) ni por letras. De hecho es tema recurrente en los programas de televisión y películas para la gran pantalla, sin embargo ellos han tomado prestado la singular forma del latín para formar palabras nuevas y las han llevado a su idioma (de nuevo siendo motivos de chistes en las comedias de situación «sitcom» por televisión «TV»). En su habla cotidiana los paleontólogos y biólogos que usan la clasificación de plantas y animales son las personas «más avanzadas» en cuanto a léxico se refiere.

Al punto que queremos llegar y recalcar es que, incluso, dicha característica de ese lenguaje se extiende más allá de las palabras y alcanza a varias de ellas -incluso llegando a formar una oración completa- y pronto lo veremos.

Nos pareció nuy útil entonces la siguiente lista de «155 Frases necesarias para una conversación en inglés» (ellos la presentan como una curiosidad) y como ya es costumbre la conseguimos viendo nuestra línea de tiempo en Twitter -si la cosa sigue como va, el Twitter será a futuro una seria competencia contra Google como buscador de información-.

Actualizado el 15 de marzo de 2015.

Hemos hecho un poco de estudio adicional y consideramos -si estamos equivocados, corríjanmos por nuestra cuenta Twitter @ks7000- que este conjunto de palabras son denominadas «frases nominales» y un concepto del mismo es el siguiente:

A word or group of words that functions in a sentence as subject, object, or prepositional object.

En castellano:

Una palabra o grupo de palabras que funciona en una oración como sujeto, objeto o objeto preposicional.

Listado de frases en idioma inglés conversacional y su traducción al castellano.

Una lista de frases utilizadas en el idioma inglés durante una conversación informal -coloquial- que hay que verlas como un todo y por ello presenta un inconveniente a la hora de traducirlas al castellano.

LetraEnglishCastellanoFrançais
Aa while backhace un tiempoIl y a quelque temps
a while agohace un tiempoil y a un moment
after a whiledespués de un ratoaprès un moment
ahead of timecon anticipación, previamenteen avance
all alongtodo el tiempotout le long
all day longtodo el díatoute la journée
all in alldespués de todo, al final de cuentasen tout
all the sameda lo mismo, da igualtous les mêmes
all the whiletodo el tiempotout en
any daycualquier día de estosn'importe quel jour
as a rulepor lo generalcomme règle
as ifcomo sicomme si
as thoughcomo sicomme si
as thoughtcomo pensécomme pensée
as muchcomo muchoautant
as usualcomo siemprecomme d'habitude
as well asademás de, tanto comoaussi bien que
as yettodavía nopas encore
ask me anotherno tengo idea
esa no me la se, preguntame otra
demande-moi un autre
at a moment's noticeen cualquier momento, de inmediatoà la notification d'un moment
at a timea la veza la fois
at any pricea cualquier precioà tout prix
at all timesen todo momento, siemprede tout temps
at every stepa cada pasoà chaque étape
at lastal finenfin
at long lastpor finenfin
at one timeen un tiempo, en una épocaà la fois
at that pointen ese momento, en esta etapa,
en ese punto (referido al tiempo)
à ce moment
at that ratea ese paso, a ese ritmoà ce taux
at the momentactualmente, por el momentoen ce moment
at the point ofa un paso de, a punto deau point de
at the same timeal mismo tiempoen même temps
at the worse possible timeen el peor momento,
en mala hora
au pire momment possible
at timesa veces, de tiempo en tiempopar moments, de temps en temps
Bbe in for itencontrarse en una situación desagradabledans une situtation désagreable
be that as it maycomo pueda ser, sea como seade toute façon
be quitssin deuda con alguien,
estar en paz o a mano (con alguien), (en inglés es frecuente llevar todo al terreno monetario, si no tienes deudas eres feliz cosa que no es necesariamente así en nuestra sociedad)
être solvable, être à portée de main à quelqu'un
be at the end of one's tetherllegar al límite, como si uno estuviera atado como una mascota.atteindre la limite, comme si l'on troussees comme un animal de compagnie.
be well of (money)adinerado, estar bien (de dinero)riche, être bien d'argent
by all means/by any meanspor todos los mediospar tous les moyents
By and largeEn general; proviene de una expresión naútica en 1706
by no meande ninguna maneraen aucun cas
by way ofpor medio depar voie de
carry one's point, gain one's point, win one's pointsalirse con la suya, lograr su propósitosortir avec elle, atteindre son but
Dday after day, day by day, from day to daydía a díaau jour le jour
day in day outtodos los díasjour après jour
down and out, down-and-out (see outcast)pobre, indigente;
preferimos la forma con guiones para formar una palabra -tal como explicamos en la introducción-.
pauvre, indigent
Eeat one's wordscomerse sus propias palabrasmanger ses mots
either wayde cualquier manera,
de una u otra manera
d'une màniere ou d'aune outre
every now and thende vez en cuandode temps en temps
every so often, every now and againa vecesde temps en temps
Ffor a changepara variaspour changer
for all intents and purposes,
to all intents, constructions and purposes
Oficialmente o de manera oficial: deriva de una ley de Inglaterra que indicaba así literlamente, jerga legal.Officiellement ou officieusement: dérivé d'une loi de l'Angleterre indiquant que literlamente, le jargon juridique.
for gooddefinitivamente, permanentementedéfinitiviment
for the moment,
for the present
Por ahora,
por el momento
Pour le moment
from now ona partir de ahoraà partir de maintenant
from scratcha partir de ceroà partir de rien
from the ground updesde el comienzoà partir du sol
from this day forwarda partir de hoy,
de hoy en adelante
à partir de ce jour
from time to timede vez en cuandode temps en temps
from way backdesde hace tiempodepuis longtemps
Ggo back one's wordromper la promesa
(acá acostumbramos decir que una "persona no es de palabra" u "no es hombre/mujer de palabra")
revenir sur sa parole
go into detailsentrar en detallesentrer dans les détails
get into troublemeterse en problemasavoir des problèms
go to wasteser desperdiciadoaller aux dèchets
good for nothing,
good-for- nothing
bueno para nada,
inútil
bon à rien
good fortunebuena fortuna, buena suertela chance
Hhard timestiempos difícilesles temps difficiles
have a hard timespasar por tiempos difícilesavoir de moments difficiles
have a way withtener una aptitud o facilidadavoir des compétences et des capacités
high timeurgente, el momento exacto paraurgent, l'heure exacte pour
his days are numberedsus días están contadosses jours son comptés
however muchpor mucho quepeu importe combien
home inalcanzar una meta u objetivo, ejemplo "The missile homed in on its target."objectif atteint
II mean it!¡Lo digo en serio!¡Je suis sériux!
I shall never got over itNunca lo superaréJe ne m'em remettrai jamais
I wish I knewOjalá supierasi seulement je savais
In doing soAl hacerloCe faisant,
it doesn' matternada importaÇa n'a pas d'importance
it doesn't make senseesto no tiene sentidoÇa n'a pas de sens
It's all the same to meMe da igualtout est pareil pour moi
It's beside the pointeso no viene al caso,
ese no es el punto
C'est à côté du point
it's new to me es nuevo para míCést nouveau pour moi
it's up to youdepende de usted, depende de tí (es tu responsabilidad)dépend de vous

it's down to you
sólo depende de usted,
sólo usted puede hacerlo
que cela dépend de vous
it's waste of timees un desperdicio de tiempo,
es pérdida de tiempo
C'est du temps perdu
in every sense of the worden todo el sentido de la palabraDans tous les sens du mot
in his dayen su época, en sus tiemposen son temps
in no timeen un instanteen un rien de temps
in old daysen aquellos tiemposDans les temps anciens
in placeen su sitio, en su lugaren place
in the meantimeal mismo tiempo,
mientras tanto
En même temps
in time
just in time
a tiempoJuste à temps
in vainen vanoen vain
it can waitesto puede esperarça peut attendre
it could have been worsepudo haber sido peorça aurait pu être pire
it was a quite jobfue un gran trabajo,
fue todo un trabajo,
costó mucho trabajo
(la palabra "quite" también se utiliza para enfatizar algo)
C'était tout un travail
it's no go,
it's no-go,
no-goes
Esto no va,
no funciona
C'est pas aller
it's a matter of timees cuestión de tiempoc'est une question de temps
Jjust aboutcasi, ya casipresque
just nowjusto ahora,
en este momento,
¡ya!
en ce moment
Kknow one's placesaber cuál es su lugar,
en su sitio
Connaître sa place
know somebody by sightconocer alguien de vistaConnaître quelqu'un par la vue
Llet's clear it upvamos a aclarar estonous allons clarifier cette
let's drop the subjectvamos a dejar el temaLaissons tomber le sujet
Mmake a show ofhacer un espectáculo deFaire un spectacle de
make hastedarse prisase dépêcher
make timehacer tiempo,
entretenerse o entretener para que pase el tiempo
prendre le temps
mind your businessocúpate de tus asuntos (en inglés todo es dinero "business" es negocio, "deal" es trato de dinero pero se extiende al ámbito abstracto del pensamiento de esa sociedad)
no te metas en lo que no te incumbe.
Occupe-toi de tes oignons
more often than notla mayoría de las vecesLe plus souvent
Nno matterno tiene importancia,
no importa
peu importe
O
off and on
intermitentemente,
que cesa periodicamente
par intermittence
on-the-spot
inmediatamenteimmédiatement
One and the sameuno y otro a la vezUn seul et même
on timepuntual, a tiempoà temps
once and for allde una vez por todasune fois pour toutes
once in a whilede vez en cuandode temps à autre
out of dateanticuadodémodé
PPiece of cakepan comidoC’est du gâteau.
piqued my interestdespertó mi interésPiqué mon intérêt
point of viewpunto de vistapoint de vue
pro and conventajas e inconvenientesavantages et inconvénients
Rrun for one's lifecorrer muy rápido,
correr como si uno fuera a salvar su propia vida
courir très vite,
courir comme si on était de sauver sa propre vie
right awayahora mismotout de suite
round the clockdía y noche,
las 24 horas
24 heures sur 24
run out ofquedarse sinmanquer de
say one's sayemitir una opiniónExprimez une opinion
S
set the pace
marcar el ritmo,
marcar la pauta
donner le rythme
side against (someone)tomar partido en contraPrendre parti contre
so farhasta ahorajusque là
sooner or latertarde o tempranotôt ou tard
speak too soonhablar muy temprano,
adelantarse
Parler trop tôt
speak one's mindemitir una opiniónExprimez une opinion
stand one's groundmantenerse firme (en un tema),
mantenerse de pie
Se tenir debout
stand to reasonmantenerse con la razón,
ser lógico
Se tenir à la raison
Ttake a sidetomar partido,
apoyar
prendre à part
take a standtomar posiciónprendre position
take into accounttomar en cuentaprendre en compte
take timetomar tiempo,
debe transcurrir tiempo para
prendre du temps
take your time!Tómate tu tiempoprends ton temps,
prenez votre temps
till the end of timehasta el final de los tiemposJusqu'à la fin des temps
time after time,
time and again
una y otra vezencore et encore
time is upse acabó el tiempole temps est écoulé,
Il se termine le temps
time outpausatemps libre,
temps mort
time will tellel tiempo dirále temps nous le dira
time's getting shortEl tiempo se vuelve corto, se acaba.Le temps devient court, juste.
that's not the pointese no es el punto,
ese no es el tema
ce n'est pas le propos
the whole year round
all year round
todo el añoToute l'année
there is no hurryno hay apuro,
no hay prisa
il n'y a pas d'urgence
throw good money after badTirar dinero a la basuraJeter de l'argent après mauvais.
to one's faceenfrentar, en su caraÀ son visage
up againstcontraContre
use your own judgmentutilize su propio juicioUtilisez votre propre jugement
Wwhat are you driving at?¿A dónde quieres llegar? (retórica)Dans quelle mesure vous voulez aller?
what for?¿para qué?¿pourquoi?
what of it?¿qué tiene?Qu'y a-t-il?
wait and seeEspera y verásattend et regarde
Yyou can take it from metú puedes creermeVous pouvez me faire confiance

Palabras que se confunden frecuentemente en el idioma inglés.

No queremos irnos sin exponeros este interesante reportaje acerca de la ortografía del idioma inglés, que si bien para nosotros la otrografía del idioma castellano es un tanto complicada, en el idioma inglés -debido al habla coloquial- ha devenido en serios errores ortográficos que derivan en confusión a la hora de su traducción y/o comprensión para nosotros. Espero os sean útiles:

  • «Lets» y «Let’s»: «Let’s» es la contracción de «let us» que se traduce, generalmente, como «vamos» -primera persona plural-; hasta acá todo bien. El problema es no incluir el apóstrofo, lo cual genera una confusión con «lets» que es la conjugación del verbo «permitir» en tercera persona, por ejemplo: «She lets dance at hall in the morning».
  • «Awhile» y «a while»: en la forma separada la vimos conformar 5 frases en la tabla principal de esta entrada pero conformando una estructura de frase (frase nominal). «Awhile» por sí sola -y la tratamos aquí aparte- es un adverbio que modifica verbos y significa, literalmente, «un corto período de tiempo» (ejemplo «He worked at home awhile»). Cosa diferente es «a while» la cual ya vimos: un artículo más un pronombre -frecuentemente usado con una preposición- contenidos en un sintagma. Ejemplo: «They will be coming in a while».
  • «Affect» y «effect»: el primero es un verbo y el segundo un pronombre, el confundirlos -consideramos- no cae en el terreno de la ortografía sino en el campo del paradigma sintagmático; no obstante según el reportaje los habitantes de habla inglesa tienden a confundirlos por la similitud de sus letras -una sola diferente-. Acá estamos muy claros en eso y hasta tenemos un refrán: «confundir la gimnasia con la magnesia«.
  • «Each other’s»: es un adjetivo posesivo recíproco -si no existe esta figura, pues la acabamos de inventar, aunque lo dudamos. Es una forma correcta y aceptada, por ejemplo: «Search at each other’s addresses, please». Lo incorrecto es usar «each others» como una forma de plural que no existe, ejemplo «Pete and Mary love each other very much».
  • «Years’ experience»: el inglés busca siempre simplificar y acortar al máximo sus expresiones, tanto es así que frecuentemente olvidan el apóstrofo+letra «s» que denota posesivo pero como la palabra ya termina en «s» -plural de «year»- no se coloca otra «s». Pero es un error ortográfico obviar el apóstrofo. Para nosotros mejor es escribir «years of experience», se parece más al castellano, opinamos.
  • «It’s» e «its»: continuamos con el problema de los apóstrofos, en esta oportunidad «it’s» es una contracción de «it is», en cambio «its» es una forma posesiva. Ejemplos: «It’s easy» o «It is easy»; «The computer help us, its job is impressive!»
  • «A» y «an»: para nosotros está sumamente claro que el artículo -neutro, sin género en inglés- es «a» pero cuando el nombre o pronombre comienza con vocal debe utilizarse «an», ejemplo: «an apple». El problema está en las palabras que comienzan con la letra hache que algunas veces no se pronuncia o es «muda» en inglés. Es así que siempre se debe escribir «an honor» y no «a honor». Hacemos notar de nuevo que la letra hache, dependiendo de la palabra, no de las sílabas, se pronuncia o no; ejemplo «high» (alto, de altura) -se pronuncia-.
  • «Everyday» y «every day»: ambas formas son correctas pero depende del contexto donde se usen. «Everyday» significa, literalmente, «diariamente» que es diferente a «every day»: «cada día»; ejemplo: «He eats pizza every day of his life» (la redundancia es para propósitos didácticos).
  • «Advice» y «advise»: acá de nuevo una letra hace la diferencia, «advice» significa consejo, recomendación mientras que «advise» es un verbo, recomendar, advertir (o informar como «Le digo y le informo…»).

Palabras que incluso a nivel académico son confundidas.

En otro interesante artículo, cuyo título incluye la palabra «stupid» la cual no comparto, no muestra varias palabras que a aún la «gente inteligente» utiliza mal, más sin embargo todo tiene su explicación (y lo siguiente justifica mi desacuerdo con el título del reportaje):

  • «Prostate cancer» y «prostrate cancer»: en castellano tenemos un refrán, «errar es de humanos, rectificar es de sabios» y he aquí que tenemos nuestra palabra dentífrico («crema de dientes» en habla coloquial) que ocasionalmente escribimos como dentrífico -palabra no reconocida por el D.R.A.E.- pero que no se presta a ningún tipo de confusión, el significado no se desvirtúa para nada. Pero en el caso del inglés vaya que es grave el asunto si agregáis una letra erre extra a «prostate cancer»: en vez de decir «cáncer de próstata» estáis diciendo «cáncer postrado» o «cáncer de acostado boca abajo en el suelo». Verbigracia: el cáncer nos obliga a postrarnos, es decir, nos debilita y nos quita fuerzas ¡pero no es un tipo de cáncer!
  • «First-come, first-serve» y «First-come, first-served»: acá volvemos a caer en el asunto de la pronunciación de las palabras completas (y que sería facilmente corregible en idioma inglés), generalmente la letra e al final no se pronuncia y lo más extraño es que «ed» pues tampoco, ¡así que de aquí proviene el error común! «First-come, first-serve» significa que el primero en llegar es el que sirve o atiende a los siguientes que llegan (así de parco es el idioma inglés). Pero «first-come, first-served» significa que el primero que llegue es servido o atendido ¡menuda diferencia! Por ello es que ellos allá, en ciertos casos -o siempre-, deberían pronunciar la «ed» (sufijo que indica pasado de los verbos regulares) para mejor comprensión -y escritura-.
  • «Deep-seeded» y «deep-seated»: es similar caso anterior y a pesar de que pronuncian expresamente el sufijo «ed» la confusión proviene de «seed» (semilla, se pronuncia «si-id») y «to seat» (sentar, se pronuncia «sit»). Acá, pensamos, es la manera de hablar muy rápido la que ocasiona el error: así «deep-seated» significa bien establecido o profundamente asentado, arraigado, «deep-seeded» toma otra interpretación como «semilla sembrada profundamente» o simplemente «sembrada (la semilla, por supuesto, que es lo único ente que se siembra) profundamente» (¡ea, tío, que mola también el castellano el acortamiento del habla!).
  • «Peak» y «peek»: de nuevo la pronunciación, «peak» es pico -de montaña-, cumbre y «peek» significa a golpe de vista, ojeada. Si a ver vamos en castellano solucionamos esto muchas veces con los acentos, como es el caso de «sabana» y «sábana» a fin de diferenciarlos al escribirlos (en este caso el castellano «es fácil»: como se escribe se pronuncia, por cada sílaba).
  • «Piqued my interest»: se traduce como «despertó mi interés» ya que el verbo «to pique» es estimular, avivar. «Peaked my interest» si bien se relaciona como «cumbre» pues no, no es correcto usarlo en esa forma.
  • «I could care less» y «I could not care less»: Ay, las negaciones ¿No nos ha sucedido eso alguna vez? Pues es mejor preguntarnos ¿Nos ha sucedido eso alguna vez? Pues sinceramente el comenzar una pregunta con una negación es muy frecuente en castellano, que no somos avaros en esto de prounciar palabras. Pero consideramos que es un error que debemos corregir (fíjemonos en los matices de nuestra habla: si comenzamos con una negación implícitamente le estamos indicando a nuestro interlocutor o interlocutora que tiene dos opciones, pero es redundante). En el idioma inglés sucede exactamente lo contrario: al usar la frase incorrecta «I could care less» está indicando que aún se preocupa, en lo mínimo por algo (tal vez será para indicar -como en nuestra negación al principio de la pregunta en castellano- que queda algo de piedad o misericordia, que se es algo magnánimo). Lo correcto es decir «I could NOT care less» o «I could’t care less» -no me preocupo en lo mínimo, o me importa menos, me preocupa menos. Preferimos no usar la contracción para dar mejor giro al hablar, enfatiza la negación «I could not care less». Por cierto, en castellano usaríamos la expresión más poética «me importa un comino».
  • «Shoo-in» y «shoe-in»: acá en castellano usamos la interjeción «¡chú!» para espantar un perro o un gato por «¡sale!» o «¡fuera!». En inglés lo comenzaron a utilizar para azuzar a los caballos en las carrera e incluso llegó a ser un verbo que significa -o es algo parecido- a apurar en una dirección. Pero una cosa totalmente distinta es «shoe-in» que significa «meter en un pie en la puerta para evitar que se cierre» y es precisamente eso loq ue hacen los vendedores que van de casa en casa. De nuevo es confundir la gimnasia con la magnesia porque suenan parecido pero se escriben diferente y tienen significados totalmente distintos.
  • «Emigrate to»: de nuevo comenzemos por el castellano: migrar es simplemente trasladarse del lugar donde se habita a otro lugar diferente (vivir, habitar en otro país o reino). Este verbo describe el acto pero no la dirección: «emigrar» es abandonar su propio país para irse al extranjero e «inmigrar» es el caso contrario, una persona que viene de un país extranjero. En inglés sucede lo mismo: «emigrate» significa «inmigrar» y es sinónimo de venir, así que lo correcto es escribir «emigrate from». El caso opuesto es «inmigrate to» que significa emigrar. Por supuesto aclaramos que «to» signifca «para» o «hacia» y «from» significa «desde» tanto en tiempo como en lugar.
  • «Sleight of hand» y «Slight of hand»: aquí vamos de nuevo con la pronunciación en inglés, ambas iguales, pero significan cosas distintas. «Sleight of hand» se usa para describir la destreza y astucia con las manos de los magos (léase prestidigadores y prestidigitadoras) mientras que «slight» es un insulto de mano -quitarse el guante y cachetear al contrario-, ojito pues.
  • «Hone in»: para resumirlo de una vez, esta combinación de palabras NO existe en el inglés (aunque hay algunos que aún lo dudan). Vamos a intentar explicarlo: «home in» significa alcanzar un objetivo, lograr una meta -por cierto, lo agregamos a nuestra lista de principio- y mucha gente cree que «hone in» es una contractura ¿?? para ello, nada más lejos de la verdad. «To hone» significa refinar, perfeccionar, así que «hone in» es algo totalmente ilógico (aunque hay algunos que aún lo defienden a capa y espada).
  • «Peace of mind» y «Piece of mind»: lo correcto es la primera expresión que significa calma, serenidad o despreocupación. La segunda significa «pedazo de mente» o pedazo de cerebro. Nos arriesgamos a sugerir que la confusión deriva de otra frase muy particular: «piece of cake» -otra adicional a la lista- y que nosotros también lo relacionamos con el trigo, «pan comido«. En francés se copian del inglés y dicen «c’est du gâteau«.
  • «Whet your appetite» y «Wet your appetite»: positiva es la primera expresión, negativa la segunda. «Wheat» es estimular el apetito y «wet» humedecer el apetito, como véis no tiene lógica en castellano pero ¡momento! a veces solemos decir «está salivando de la alegría» y salivar es humedecer, cuando se tiene apetito se saliva, se humedece la boca, tal vez de allí el error común.
  • «For all intensive purposes»: vamos, no hallamos explicación lógica a esto, debería ser «for all intents and purposes» que a su vez es abreviado de una ley de Inglaterra que rezaba «»to all intents, constructions and purposes» y que se traduce como «oficialmente» o «de manera oficial». Ah, otra más para la lista de arriba.
  • «One and the same» y «one in the same»: la primera es la correcta y significa uno y otro a la vez, por ejemplo «Melissa was father and mother one and the same» que se traduce como «Melissa fue padre y madre a la vez». «One in the same» no tiene sentido, es una distorsión.
  • «Case in point»:
  • «Make do» y «make due»: «make do» es una abreviatura de «to make something do well» o «to make something sufficient». Es por ello que que, incorrectamente, escriben «make due» por «hacer lo debido». Un ejemplo que degusto y os traigo: «When life gives you lemons, you make do and make lemonade!».
  • «Due diligence»: nace a partir de una jerga legal, haga las diligencias debidas de concer con quién se está haciendo negocios. Es totalmente diferente a «do diligence» que se puede aplicar a cualquier otro proceso legal, incluyendo el conocer con quien se hace tratos legales.
  • «By and large»: proviene de una expresión naútica de 1706 y significa «en general». Por otra parte «by in large» no existe ni tiene sentido (aunque tampoco no mucho la expresión original y correcta).

Humor.

Veamos al genial Bill Murray (actor en la película «Cazafantasmas», entre otros éxitos) anunciando con trabalenguas en su idioma natal inglés los «geniales y novedosos» LASERdiscs (que a la final fueron un fracaso en ventas):

Fuentes consultadas.

En idioma castellano.

En idioma inglés.

Download PDF
Kevin Mitnick (fotógrafo: Matthew Griffiths).

Ingeniería social en informática.

Download PDF

La ingeniería social, aplicada al mundo de la informática, se basa en la premisa de que el usuario, ser humano al fin, es el eslabón más débil de la cadena, por lo tanto el más fácil de atacar.

Desde hace muchísimos años ya sabíamos esto pero, a nuestro juicio, quien popularizó el término gracias al éxito de la normalización (esto es, expresarlo en reglas, pocas por demás, y aplicarlas al pie de la letra y masivamente) fue Kevin Mitnick.

  • Todos queremos ayudar.
  • El primer movimiento es siempre de confianza hacia el otro.
  • No nos gusta decir «no».
  • A todos nos gusta que nos alaben.
Kevin Mitnick (fotógrafo: Matthew Griffiths).
Kevin Mitnick (fotógrafo: Matthew Griffiths).

Aunque vosotros no me lo estáis preguntando, igual os lo digo: la letra k de nuestro dominio web, donde están alojadas estas humildes líneas, es en honor a dicho cracker. Ah, y la fotografía que encabeza este artículo es Mister Kevin Mitnick. Dicho esto imaginad la cantidad de visitas que recibirá este entrada para divulgar nuestra idea (si alguien anteriormente la ha publicado -la idea que van a leer-, comunicadlo de inmediato por favor 😉 , arriba tenéis nuestra dirección en Twitter. ).

https://twitter.com/ks7000/status/731605936020787202
https://twitter.com/tecnologiapure/status/736601592661696512

Introducción.

Así pues, arrancamos el 2016, con el enfoque a la seguridad donde más falla. ¡Sabíais que en los accidentes de aviación un alto porcentaje de casos ocurrieron por impericia y/o confusión y/o conducta natural del ser humano! Y estamos hablando de la tripulación, no hablemos ya del personal en tierra: mecánicos e incluso los que pesan el equipaje que llevamos, o los que montan la carga o equipaje en los aviones (que para todos los efectos es lo mismo, en este caso).

Pero la Administración Federal de Aviación (la FAA por sus siglas en inglés, precisamente del país que desarrolló masiva y comercialmente la aviación) dedica mucho más tiempo en encontrar la solución para prevenir futuros accidentes que tiempo en investigar las causas de cada accidente. Es decir, descubrir qué y cómo se estrella un avión toma tiempo y trabajo, pero prevenir dicho error a futuro es aún más trabajoso. La razón es simple: cuesta dinero implementar políticas de seguridad. Añada el hecho, además, que no se debe eliminar ni interferir en ninguna de las políticas de seguridad implementadas anteriormente, pues veis entonces que el asunto no va nada fácil, en lo absoluto. Tal como dice el hacker español Chema Alonso (ahora ejecutivo en Telefónica España) : «la gente quiere estar segura PERO NO QUIERE PREOCUPARSE POR LA SEGURIDAD«

Por estos lares hay refrán que ilustra lo anterior: «estar bien con Dios y con el diablo».

Un poco de historia.

El ejemplo de los aviones os lo colocamos para entrar de lleno en la seguridad informática, pero primero debemos describir, lo más breve y resumida posible, las «políticas de seguridad» implementadas anteriormente.

Por allá en el siglo pasado, a principios de la década de los noventa, utilizábamos el protocolo IPX/SPX de Novell Netware, un sistema operativo de red muy adelantado a su tiempo. No tuvimos acceso a internet de manera masiva hasta 1997 así que esas pequeñas red de área local con cable coaxial de 10 mbps eran verdaderas islas de datos. Vale decir que al desconectar un solo nodo por cualquier motivo, «colgaba» la red completa debido al uso de token, así que si alguien quería conectarse a la red pues no pasaba desapercibido, nos dábamos cuenta de inmediato. Y cuando por fin llegó el internet implementamos el TCP/IP para ciertas máquinas «avanzadas» en la red para repartir la conexión de marcado telefónico de los flamantes y nuevos modem PCI de 33 kbps (y luego los de 56 kbps) y todos tan felices y tan contentos, los datos del sistema de facturación e inventario corrían con cierto nivel de seguridad. Incluso por allá por 2004 ó 2005 hubo un incidente mundial del protocolo TCP/IP que nos dejó incomunicados por 2 días pero nunca se cayó el IPX/SPX.

Incluso hoy en día, en negocios pequeños, y a pesar que solo usamos TCP/IP con el fast ethernet o gigabit ethernet (100 ó 1000 mbps) con RJ45 (que detecta colisiones y que permite que alguien dentro de la empresa coloque una «T» para hacer un «ataque de hombre en el medio» por hardware o, más fácil aún, conectar un ordenador portátil a cualquier conector empotrado en pared para hacerlo por software) este sistema basado en «isla de información» sigue siendo relativamente seguro. Agreguemos el factor de red inalámbrica «wifi» y veremos que un atacante, sin necesidad de estar dentro de la empresa pero dentro del alcance de nuestra antena de red descartaría el método primero ya que le sería más fácil y cómodo «hackear» nuestro enrutador inalámbrico. Pero la tecnología llegó para quedarse, el inalámbrico tiene claramente sus ventajas que podemos observar acá:

Pueden intentar forzar la conexión inalámbrica (si usan WEP pues de hecho se conectarán indefectiblemente) o de irse de lleno y aplicar ingeniería social a nuestros empleados, más fácil aún.

Claro está, todo lo descrito anteriormente, conectarse físicamente a nuestra red de área local, sería el primer paso para un atacante, lo siguiente sería tener las contraseñas necesarias para lograr escalar privilegios ya sea en el mismo enrutador, en los sistemas operativos de cada computadora o en las bases de datos de los servidores. De nuevo la modernidad facilita las cosas: un atacante en cualquier parte del mundo intentará entrar por medio de nuestro proveedor de internet, pero a favor nuestro están los «muros de fuego» tanto de los enrutadores -aparatos o computadoras que hagan las veces de enrutador(es)- como en los sistemas operativos modernos de cada computadora. Si queréis ver un método sencillo de protección con un muro de fuego «firewall» escrito con IPTABLES visitad este enlace, es un ejemplo sencillo para proteger nuestra red de área local.

Como siempre hay quien puede explicar mejor que nosotros, consideramos que el artículo de Alejandro Alcalde en su página web «El Baúl del Programador» bajo el título de «Cómo se almacenan tus contraseñas en internet (y cuando la longitud de la misma no importa)«, os prometemos que es una explicación básica, sencilla y directo al grano.

A pesar de todos estos obstáculos que hemos puesto para mantener a buen resguardo nuestros datos, he aquí en este mensaje o «tuit» que nos explican cómo obtienen las contraseñas hoy en día los «ciberdelincuentes«:

Método que aspiramos combatir.

Como veis volvemos al principio de nuestro artículo: lo más fácil es lograr que los mismos empleados sean los que nos entreguen sus contraseñas, y si se niegan decirlas pues podemos hacer que nos las muestren. Esto se logra muchas veces con notar cual empleado de atención al público ha estado alejado de su computadora, generalmente para comer, y que llega a introducir su contraseña personal: allí lo abordamos con cualquier excusa, una consulta de precios, por ejemplo, mientras nos fijamos bien qué teclea, nos fijamos en sus manos ya que estará entretenido viendo el monitor y no se percatará de qué observamos atentamente las teclas que presiona. Aunque no lo creáis, hay personas que tiene una agudeza visual y excelente memoria para hacer esta pesca de contraseñas, así, «en vivo y en directo». Es por ello que nuestros bancos, guardianes de nuestro dinero, lo repiten hasta el cansancio: utilizemos contraseñas largas, amén de cambiarlas con cierta frecuencia.

¿Cómo almacenar información de manera segura?

Acá debemos volver al caso de las redes de área local de negocios pequeños, ya que los grandes utilizan el protocolo seguro https el cual encripta la información, previa implementación de claves públicas y privadas (ver anteriormente el ataque de «hombre en el medio»). Dichos sitios web pagan un alto costo por un certificado que garantiza, a nivel mundial, que uno está realmente conectado con el dominio web que uno introdujo para navegar y que, además, los datos enviados están encriptados, dando al traste con el plan que cualquiera haya implementado para interceptar los paquetes de datos que viajan mediante TCP/IP, el protocolo de red de facto.

En un negocio pequeño los servidores de datos los podemos implementar para que soporten https pero con la salvedad de que a cada ordenador le configuremos una excepción de seguridad -o instalemos el certificado generado por nosotros mismos con ayuda de SSH y scripts automatizados y masivos- en cada navegador web que tengan instalado cada ordenador con GNU/Linux. Todo sea por ahorrarnos un dinerillo en certificados digitales garantizados por terceros y servicios DNS.

Hypertext Transfer Protocol Secure (HTTPS).

Sin profundizar demasiado en este punto, solo vale recordar que el protoclo HTTPS es equivalente al protocolo HTTP pero establece una conexión segura, es decir, cifra la información para evitar que en el camino entre el usuario y el servidor cualquier tercera persona sea capaz de leer la información, siendo demasiado difícil su descifrado por no autorizados. En un principio utilizaba SSL pero luego se decantaron por un protocolo más seguro llamado TLS, sobre ambos pueden ahondar en su estudio en este enlace. El punto clave a tener en cuenta es que contamos con una conexión privada entre el usuario y nuestro servidor con la cual se puede enviar información sensible como números de tarjetas de crédito, contraseñas, etc.


Actualizado el sábado 30 de enero de 2016:

Leyendo las noticias acerca de las vulnerabilidades descubiertas por los hackers -Dios nos cuide NO sean crackers- nos enteramos que, bajo ciertas circunstancias muy especiales, el protocolo HTTPS puede ser vulnerado debido al uso de números primos «no seguros» -léase números primos «pequeños»- y el uso masivo de handshakes con el método Diffie-Hellman para reunir suficientes datos y aplicar un algoritmo antiguo muy conocido se puede llegar a descifrar los datos que transporta dicho servidor web. Por supuesto que estamos simplificando al máximo, allí tenéis los enlaces web en inglés con los detalles a fondo.


Guardando datos a buen resguardo.

Pero, aunque hayamos logrado resolver por alguna de las dos vías mencionadas en la sección anterior nos quedaría otro problema: ¿Cómo se guardan las contraseñas de los usuarios en las bases de datos -o en los sistemas operativos- para garantizar que estén a salvo de ojos maliciosos?

Volviendo al siglo veinte, por esa época las computadoras tenían muy poco poder de cálculo y debíamos arreglarnos con pocas líneas de código. Por 1994 ó 95, a petición de los usuarios que querían cuidar sus nuevos monitores CRT a colores, cuya pantalla se «quemaba» con la misma imagen fija (por ejemplo la consulta de precios, aún hoy es siempre la más usada) y dejaba marcas «fantasma» en ellas, tuvimos que programar un protector de pantalla basado en la teoría de fractales.

Para guardar los datos en disco duro de «manera segura», tampoco sobraba el poder de cálculo, así hicimos una función sencilla (y también muy fácil de descifrar) muy parecida a la que aún utiliza el lenguaje PHP con el función str_rot13 (podeis leer acerca de los métodos de encriptación desde lo más fácil hasta lo más difícil en este enlace en inglés). Para poder entender dicha función hay que tomar en cuenta que esos datos debían cifrarse y descifrarse rápidamente y sin mayor consumo de ciclos de reloj del CPU. Y aquí viene un concepto fundamental: debe funcionar rápidamente en ambos sentidos.

Aquí ustedes se estarán preguntando ¿porqué aún el lenguaje PHP ofrece esa función de encriptado siendo tan fácil de descifrar? De nuevo la respuesta es el costo. Dicho método sigue siendo barato en cuanto a uso de hardware se refiere y es utilizada para guardar extensos párrafos como éste, que vois disfrutáis, en una base de datos.

Suponiendo que, aunque obtuvieran las contraseñas para entrar a esa base de datos, pues no podrían modificar nada del texto pues resulta ininteligible a primera vista al ser humano y si llegaren a modificar algo, por puro vandalismo, nos percataríamos del acto ya que la entrada de blog mostraría texto extraño al ser descifrada (también podríamos realizar una función que copie -«respalde»- los textos y cada cierto tiempo -usando crontab– los compare y detecte alteraciones).

Si al párrafo anterior le aplicamos la función str_rot13 veríamos lo siguiente (como será guardada en la base de datos):

Fhcbavraqb dhr, nhadhr boghivrena ynf pbagenfrñnf cnen ragene n rfn onfr qr qngbf, chrf ab cbqeína zbqvsvpne anqn qry grkgb cbedhr erfhygn vavagryvtvoyr n cevzren ivfgn ny fre uhznab l fv yyrtnera n zbqvsvpne nytb cbe cheb inaqnyvfzb abf crepngnevnzbf qry npgb ln dhr yn ragenqn qr oybt zbfgeneín grkgb rkgenñb ny fre qrfpvsenqn.

Debo hacer la observación que dicha función NO soporta los caracteres extendidos (a partir de la versión 7 dará soporte a caracteres UNICODE), lo cual no debe ser problema para el lenguaje html que tiene sus códigos especiales para representarlos, si deseáis saber más podeis acceder a nuestro tutorial sobre HTML.

Las funciones «hash».

Una función «hash» toma un valor, aplica un algoritmo predeterminado y produce un resultado único, aunque ALGUNAS VECES dicho resultado puede también ser obtenido con otro(s) dato(s) diferente(s), lo cual es llamado colisión. ¿Sencillo, no? Si quereis saber más pues aquí tenéis el enlace a la Wikipedia sobre el tema.

Como podréis observar, la función del lenguaje PHP que presentamos anteriormente es una función «hash» y si analizamos como funciona (restando 13 de cada valor decimal que describe a cada carácter ASCII) dejando intactos los caracteres no alfabéticos -del alfabeto inglés- podemos llegar a la conclusión que no tiene colisión alguna.

Funciones «hash» criptográficas.

Pues bien, las funciones «hash» criptográficas en realidad NO existen. Lo que siempre ha existido es la criptografía casi desde el mismo invento de la escritura: a pesar de que antes del siglo XX un porcentaje muy pequeño de la población sabía leer y escribir siempre hubo la necesidad de ocultar la información, por ejemplo las órdenes dadas en el ejército. En la Segunda Guerra Mundial se utilizó una computadora especialmente diseñada para descifrar los mensajes del Tercer Reich Alemán, para lo cual fue muy exitosa y fue cuando se valoró enormemente el uso de los ordenadores en el área de la criptografía.

Muy importante destacar que la en la criptografía el proceso es reversible, es decir, podemos obtener el texto original. De aquí en adelante hablaremos de cifrado en un solo sentido; pudieramos llamarlo -en la práctica- como «cifrado irreversible».

Para esta labor se escogieron unas funciones «hash» que tienen características bien adecuadas para el trabajo:

  • Que no tengan colisiones -ya hablamos de la función PHP str_rot13-.
  • Que tenga bajo coste en recursos de hardware y tiempo.
  • Que no se pueda inferir o detectar un patrón por medio del análisis y comparación de varios resultados con el mismo método -más adelante lo veréis con WinZip -.

En este último punto es cuando la función analizada, PHP str_rot13, falla y es principalmente porque NO encripta los espacios, los cuales a su vez delimitan las palabras y uno de los pilares fundamentales para el descifrado es eso: dónde comienza y donde termina cada palabra. Además tampoco cifra los demás caracteres, con lo que, si quiere, pudiéramos decir que en realidad cifra a la mitad (y por eso es que es de tan bajo coste para cifrar párrafos y hojas enteras de información).

WinZip.

Esta entrada no puede estar completa sin mencionar al software de compresión llamado WinZip, un estándar o norma de facto en computación. Aunque lo usamos desde 1997 no fue hasta el año 2004 en su versión 9.0 que trajo la novedad de encriptación de AES 128 bits para máquinas de bajo rendimiento y AES 256 bits para máquinas de alto rendimiento (es decir, lo hicieron así para que uno pudiera ponderar nivel de seguridad contra tiempo usado para encriptación; con las máquinas de hoy en día de 16 núcleos y 32 gigabytes de RAM pues es imperceptible la diferencia de tiempo entre ambas).

He aquí un panorama de la estructura de archivo de un fichero con extensión .zip normal:

Como usábamos en aquella época el correo electrónico para compartir el código fuente, decidimos encriptar con AES 256 bits y un módulo pequeño, pero importante, y perdimos su contraseña. Lo tuvimos que reescribir y, hasta el sol de hoy aún no hemos podido descifrarlo.

«Advanced Encryption Standard»

Advanced Encryption Standard fue promovida por el Instituto Nacional de Normas y Tecnología («National Institute of Standards and Technology» o NIST por sus siglas en inglés) en el año 2001, y fue propuesta por dos criptógrafos belgas Joan Daemen y Vincet Rijmen con un bloque de 128 bits y longitudes de clave de 128, 192 y 256 bits convirtiéndose en una norma de encriptación a nivel mundial. El gobierno federal de los Estado Unidos de Norteamérica considera la clave de 256 bits lo bastante segura para encriptar documentos de muy alto nivel de importancia, información muy secreta. Es posible descifrar incluso hasta las claves de 256 bits pero el esfuerzo y consumo de hardware consume muchos recursos, sin embargo sigue siendo la manera más viable de cifrar y descifrar información. Hemos de recalcar que funciona en ambos sentidos: una cadena de caracteres (información a proteger) se encripta y se puede enviar a otra persona. Si la otra persona no conoce la clave tardará muchísimo tiempo y esfuerzo en «descubrir» la cave utilizada. Pero para el que encriptó los datos puede revertir la operación y recuperar la información.

Si quieren leer un detalle sobre cómo se genera una llave AES notarán que hay una pequeñísima posibilidad de que comprimiendo y encriptando miles de archivos individuales con la misma contraseña, en algún momento se producirán 2 iguales que si se tiempo y paciencia podrán conducir a una pista sobre la contraseña, pero que se puede prevenir con usar llaves de 256 bits. Información para desarrolladores de software interesados en usar las últimas versiones de WinZip id a este enlace web. En ese último enlace, la mar de especificaciones, podemos leer que dicho software de compresión almacena un CRC (comprobación de redundancia cíclica, inventada por W. Wesley Peterson en 1961) del archivo original -sin comprimir, sin encriptar- en la cabecera del archivo comprimido para que después de desencriptar y descomprimir puedan ser comparados y verificar que la información anhelada se transmitió correctamente (recuerden nuestro caso de envio de código fuente por correo electrónico). Dicho CRC es ampliamente utilizado desde que se inventaron los CD, y simplemente es otro método de cifrado que exhibe un resultado de longitud fija pero con muchas, muchísimas colisiones, lo cual lo descarta de plano para el cifrado y sirve más bien como herramienta auxiliar. Cuando utilizábamos discos flexibles de 5,25″ (y luego 3,5″) los errores de hardware en la escritura, o luego la manipulación física por parte de nosotros (para llevarlos al trabajo, a la universidad) hacían muy necesario el uso del CRC para tener al menos una certeza que quedó bien grabado {y era sacarlo de la disquetera A y comprobarlo en la disquetera B, por eso el disco duro en los sistemas Windows se llama «C», -amigos «linuxeros», no más chistes al respecto, por favor- 😉 }

En este otro enlace recomiendan aplicar «salt» a las rutinas de encriptación para WinZip (desarrolladores de software) pues ya hemos advertido de las posibles debilidades del algoritmo de encriptación, así que se pueden «fortalecer» con nuestras propias «claves», si son aleatorias, pues mejor. Por último, y de nuevo, nuestros bancos tienen la razón: usemos contraseñas largas (y vamos a cambiarlas con cierta frecuencia).

CRC.

Acá hacemos una pequeña pausa para recomendar la lectura de un artículo patrocinado para una famosa página web -vereis quién hace publicidad, lo veréis- donde explican, en idioma inglés, de manera fácil y amena el porqué se debe hacer la verificación de integridad de los datos transmitidos, y rápidamente colocan ejemplo en lenguaje C#. Para que veáis que todos los programadores tenemos nuestros momentos de ir a las raíces, a las bases y principios de los ordenadores (y si podéis ayudar al autor en su programación, hazlo, por favor).

Cifrado en un solo sentido.

Sin embargo hay casos donde en realidad no se necesita recuperar la información cifrada pero necesitamos que dicha función no tenga colisiones, es decir, que la COMPARACIÓN de dos datos cifrados, en máquinas independientes, produzcan exactamente el mismo resultado o «hash». En este caso no se busca encontrar el texto original, ya que es prácticamente imposible revertir el procesado de cifrado para conocer la información.

Para entender este proceso debemos siempre tener en cuenta que el «hash» generado por determinado método de encriptación conocido solo producirá un resultado único que será el que guardemos en nuestra base de datos, o en nuestro disco duro y solamente el que conoce la información podrá repetir de nuevo el «hash» y así podremos comparar con el «hash» generado anteriormente; si son iguales pues se valida el proceso de identificación. Esto garantiza que la persona es quien dice ser, es dueño de la información, el «hash» es como una «huella» inconfundible y por eso lo hace adecuado para garantizar el acceso a sistema de cómputo por medio de contraseñas.

De hecho es tan efectiva que si nosotros olvidáramos nuestra contraseña para acceder a nuestra cuenta bancaria, por ejemplo, la única manera que el banco nos pueda ayudar es borrando el «hash» de la contraseña almacenada y permitirnos generar una nueva, ya que descifrar el «hash» es, como dijimos, prácticamente inalcanzable. Por demás está decir que quienes llevan sistemas bancarios cobran buen dinero al banco por «reseteos» de contraseña, gasto que a la final, de una u otra manera, terminaremos pagando todos los clientes. Pero el almacenamiento seguro de nuestras contraseñas, incluso bancarias, es otro proceso de ingeniería social que no discutiremos en esta entrada, allí hay bastante tela que cortar y sirve para una entrada en nuestro blog totalmente nueva sobre ese tema.

En este punto volvemos a insistir que siempre hay gente que «sabe más que uno» ya sea por sagacidad o por la fuerza bruta ¿Por qué decimos esto? Existe el proyecto Ophcrack en el cual se han dado a la tarea de utilizar «diccionarios» de contraseñas comunes (en diversos idiomas) haciéndoles hash con los diversos métodos que enunciaremos para así comparar una contraseña obtenida ilegalmente con las almacenadas (y conocidas) en una base de datos monstruosa (algunas tablas llegan a alcanzar los 2 Terabytes, es decir, 2000 gigabytes). En este artículo (en idioma inglés) dan cuenta de las llamadas «tablas arcoíris» («rainbow tables»), cómo funcionan y cómo trabajar con ellas. Si nos ponemos a ver la tarea hasta parece estúpida sino fuera porque debemos considerar que en este siglo XXI la información es sinónimo de dinero eso hace que esta gente trabaje tanto en estos proyectos (luego veremos que le podemos dificultar aún más ese trabajo que ellos tienen por medio de un método adicional de hashing).

MD5.

Desde los años noventa usamos el algoritmo MD5 aunque no recordamos exactamente cual año. Lo más probable es que haya sido con Windows 95, pero no estamos totalmente seguros. Lo que si es cierto es que ya entrado el siglo XXI se consideraba seguro y muy capaz de sustituir al vetusto CRC comentado anteriormente. De hecho aún se utiliza por su bajo coste (ver párrafos anteriores) para publicarlos en las descargas de las páginas web: si aplicamos el MD5 al archivo descargado y comparamos dicho resultado al publicado en la página web de donde lo descargamos es muy altamente probable que tengamos una copia idéntica a la que reposa en la páginas web. Establecido como norma desde su invención, devuelve como resultado una número de 32 dígitos en hexadecimal y funciona «rellenando» con bits -mínimo 1, máximo 512- (atentos que más adelante tomaremos prestado este concepto) y agregando hasta completar a un múltiplo de 512. Allí realmente comienza a aplicarse al algoritmo, que al final redunda en un dígito de longitud fija que es fácilmente manejable en una base de datos.

En el año 2004 se demostró una colisión y hubo la necesidad de buscar un método de cifrado mejor. Antes de continuar, comentamos que existió un algoritmo MD4 con el cual no tuvimos ni tenemos experiencia. También es justo comentar que fue el profesor Ronald Rivest su autor (y padre de toda la serie MD del 1 al 5, ea, ¡prolijo el profesor!).

Si revisamos el lenguaje PHP, mayormente utilizado para generar páginas web dinámicas, tenemos la función llamada -qué original- md5(), he aquí un ejemplo:

<?php $hash = md5('contraseña a encriptar'); ?>

SHA1

Otro algoritmo soportado de manera nativa por el lenguaje PHP es la función SHA1 el cual produce 40 dígitos en hexadecimal, de nuevo dos ventajas, longitud fija y numérico, dos características muy apreciadas en el manejo de base de datos y tablas indexadas. También fue logrado su ruptura por gente muy voluntariosa. En fin, que los algoritmos fueron hechos para romperse, más ahora que se avecina la computación cuántica donde una «variable» en «memoria RAM» puede tener diferentes valores según «el ángulo» de donde se mire. Lo poco que podemos agregar con respecto a MD5 es que es un poco más seguro.

Tipos de cifrados en PHP (MD5, SHA1 y Salt).

En realidad esta idea no es nuestra, para nada, tuvimos la oportunidad de conocerla hace varios años divulgada por medio del Twitter:

El artículo completo lo podeis leer en este enlace. En esencia es combinar ambos cifrados pero con la inclusión de una «firma» adicional -en este caso la página web escrita en PHP- que solamente el programador conoce y que es llamada «salt» cuya traducción al castellano es «sal» ya que, si a ver vamos, le da un «sabor» distinto a las contraseñas. La idea es ayudar al usuario agregándole longitud -y complejidad- a la misma a la hora de ser «hasheada». Si lo pensamos bien, tiene la «debilidad» de que dicha «salt» (así la llamaremos) no debe ser extraviada, porque la usaremos cuando el usuario, en otra oportunidad de ingreso, se compare con la almacenada en nuestra base de datos. Más adelante veréis que dicha «salt» viene ahora incrustada por defecto en el lenguaje PHP.

Otros tipos de cifrado.

Ya casi llegamos al punto de nuestra propuesta, pero antes debemos enseñar que, como era de imaginarse, existen muchos otros tipos de cifrado. Volviendo al nuestro querido PHP existe la función avanzada llamada (si, están leyendo bien) «hash()«. Para ser más precisos dicha función necesita tres parámetros: primero el tipo de encriptación, segundo, el mensaje a ser cifrado (en nuestro caso, la contraseña del usuario) y tercero en que formato se entrega, ya se en binario o hexadecimal.

El primer parámetro acepta los siguientes tipos de cifrado (versiones PHP 5 >= 5.1.2, PHP 7, PECL hash >= 1.1):

  • MD2.
  • MD4.
  • MD5.
  • SHA (cinco variaciones).
  • RIPEMD (cuatro variaciones).
  • WHIRLPOOL.
  • TIGER (seis variaciones).
  • SNEFRU (dos variaciones).
  • GOST (dos variaciones).
  • ADLER.
  • CRC (dos variaciones).
  • FNV (cuatro variaciones).
  • JOAAT
  • HAVA (quince variaciones).

Como podeis observar, las opciones de combinación son muchas, así que no os limiteis en utilizar solo MD5 y SHA, hay muchas otras opciones.


Actualizado el sábado 23 de enero de 2016:

Un estudiante paquistaní que utiliza C# en Ubuntu (y además no enseña sobre cómo manejar ese entorno de programación, eso merece otra entrada completa en nuestro blog -a pesar de los detractores de «C sharp»-) nos indica que es mejor utilizar SHA512 + SALT, claro vosotros estad claros en que plataforma estáis programando y si lo permite, siempre es bueno tener muchas alternativas porque no se sabe de cual lenguaje uno va a echar mano a la hora de asegurar nuestro trabajo en este mundo globalizado y con tanto «hacker» suelto:

Como nota adicional nos enteramos que la opción «SALT» agregada por el usuario será descontinuada en su uso en la versión 7 del lenguaje PHP y será sustituida por la ya soportada generación automática de la misma (muchas gracias sr. Ángel):

Más adelante volveremos a tocar el tema, porque ¿Cómo recordar la «SALT» utilizada si fue generada aleatoriamente -con ayuda de la hora del servidor- para luego recuperar la contraseña? La solución es ingeniosa, ya lo vereis.


Combinaciones normalizadas.

El lenguaje PHP ofrece unas funciones, extensas, para el tema de la encriptación de manera nativa, facilitándonos la vida a nosotros los programadores pero manteniendo a raya el coste para el servidor donde esté alojada la página web.

Una terna de ellas es muy interesante, avalada con otra adicional, todas ellas siempre pensadas a un proceso y respuesta rápida a la página web solicitada lo que evita ciertos ataques maliciosos. POR EJEMPLO un atacante puede intentar hacer «login» -a sabiendas de ser errado- a determinado sitio web y por herramientas tomar el tiempo que tarda en responder el servidor. Si tarda 1 ó 2 segundos (una eternidad en tiempo de ordenadores) pueden iniciar ataques desde varios sitios para hacer colapsar el poder de procesamiento cuando realiza el descifrado de dichos envios. Más información en el siguiente «tuit» («tweet»):

Las tres funciones son:

  1. hash_init( algoritmo_deseado ).
  2. hash_update( respuesta_obtenida_de_hash_init , cadena_a_encriptar ).
  3. hash_final( respuesta_obtenida_de_hash_update ).

La función hash_update() puede ser repetida tantas veces se desee o sea necesario para agregarle la o las «SALT» comentada anteriormente. Como vemos es una solución normalizada, «estandarizada» si queremos usar el anglicismo. He aquí un código de prueba:

<?php
  $contra = hash_init('md5');
  hash_update($contra, 'contraseña a ser encriptada');
  hash_update($contra, 'Se le agrega SALT para complicarlo');
  echo hash_final($contra);
?>

Como pueden observar es estructurada la propuesta, son cuatro líneas mínimo. La función que la complementa es hash_equals(), solución nativa en este lenguaje y que devuelve verdadero o falso cuando compara dos «hash»: el hash que leemos de la base de datos (guardada cuando el usuario se registró) y el «hash» calculado al momento de hacer «login» o autenticación cuando el usuario regresa en otro día y/o momento.

Repetimos: hay muchos otros algoritmos y muchas otras funciones para encriptar en un solo sentido, veamos la función crypt() trabajando con la función hash_equals():

<?php
  $expected = crypt('12345', '$2a$07$usesomesillystringforsalt

Esta última función hash_equals() se describe como «Timing attack safe string comparison«, es decir, «comparación de cadena segura ante ataque de tiempo» la cual describimos en el segundo párrafo de esta sección y que nos ayuda a proteger nuestro servidor web y/o servidor de datos.

En los enlaces nombrados podeís ahondar mucho en el tema, aquí solo queremos tener una base para emitir una propuesta de solución a la ingeniería social aplicada a nuestros empleados, sufridos usuarios de los sistemas que programamos e implantamos.

Bouncy Castle.

Bouncy Castle es una propuesta de software libre (regida por esta licencia) escrita originalmente para Java -y luego C#- en respuesta a la restricción de exportación de técnicas de encriptamiento hechas en los Estados Unidos de Norteamérica. Recordad, o por si no lo sabiaís, que si vives o estudias en ese país y te daís a la tarea matemática de desarrollar nuevos algoritmos, es OBLIGATORIO comunicarlo al Buró Federal de Investigaciones (FBI) sobre tu trabajo, o tendrás serios problemas con la Ley. Y precisamente Australia, sede de dicha organización «Bouncy Castle», era originalmente una gigantesca prisión donde enviaban al fin del mundo -en esa época- a toda suerte de convictos y quebrantadores de leyes del Reino Unido, así que no se toman su independencia tecnológica a la ligera, no señor.

La necesidad de no reinventar la rueda cada vez que se necesitaba encriptar algo dio origen a tal organización con tan gracioso nombre, incluso tienen una caricatura donde se mofan de ellos mismos:

 Bouncy Castle

Podeís estudiar un estupendo trabajo utilizando dichas API’s con Criptografía de Curva Elítipca en este enlace web.

El lado oscuro de la Fuerza.

Actualizado el sábado 23 de enero de 2016:

Lamentablemente hay quienes utilizan la fuerza del oponente para desviarla y canalizarla en beneficio propio, tal como lo hace el judo -arte marcial-.

En este artículo, de hace varios años ya -2013-, podréis leer y conocer acerca del peligroso Cryptolocker que, aunque ataca sistemas basados en Windows, también han salido versiones para GNU/Linux. Así que cuidadito pues, una herramienta puede ser utilizada HERMOSAMENTE para hacer el bien 😎 tanto como para hacer el mal. 8(

Actualizado el martes 02 de mayo de 2017:

La última actualización de la distribución Kali Linux -la cual es muy utilizada por sus herramientas de seguridad y análisis- ahora tiene una base de apoyo para ser instalada en «nubes» de máquinas virtuales que operen en conjunto y de manera coordinada para «crackear» contraseñas. Evidentemente que una buena herramienta puede ser convertida al uso maligno y destructor. 🙁

«Inventamos o erramos».

Don Simón Rodríguez: "Inventamos o erramos".
Don Simón Rodríguez: «Inventamos o erramos».

Don Simón Rodríguez acuñó la frase en 1828, cuando recién nacía nuestra República y necesitábamos labrarnos nuestro propio camino. No se trata de improvisar constantemente sino estudiar, analizar y proponer algo que observemos sea viable, posible y, más que todo, práctico. Es por ello que esta entrada ha quedado un poco larga, ya que sin una base de donde partir para proponer estaríamos haciendo eso, improvisando.

Nuestra propuesta.

He aquí que, luego de una larguísima explicación, llegamos al punto de exponer nuestra idea para combatir, al menos una, de las tácticas empleadas en la ingeniería social para obetener nuestras contraseñas. Como demostramos, nuestra cadena de caracteres utilizada para identificarnos como usuarios legítmos en cualquier sistema de cómputo ha de ser lo más larga posible. Dicha cadena larga tiene dos beneficios:

  • Primero cuando nos registramos en el sistema deseado como usuario, en la creación del «hash» que será almacenado en la base -y tabla- de datos correspondiente.
  • Segundo cuando nos volvemos a conectar, vía protocolo https, de nuevo al sistema de cómputo, ya que también la información se encripta al ser enviada, mientras más larga más difícil de desencriptar.

Proponemos, entonces, no una cadena larga como contraseña, sino una cadena de al menos 7 caracteres alfanuméricos:

  • Los tres primeros que sean alfabéticos, mayúsculas y/o minúsculas.
  • Un caracter especial, tal como «_», «*», etc.
  • Los tres últimos que sean numéricos, del cero al nueve.

Esa sería nuestra contraseña, ¿dónde está el truco de seguridad, si recomendamos MENOS caracteres de longitud? Pues que luego que introduzcamos nuestra contraseña completa, de allí en adelante pulsar todas las teclas que considereís conveniente E INCLUSO LA DIGAÍS EN VOZ ALTA, SI TENEÍS ALGUIEN AL LADO OBSERVANDO TU INGRESO.

«Algoritmo para ofuscar técnica de ingeniería social» por Jimmy Olano está licenciado bajo Creative Commons Attribution-ShareAlike 4.0 International License.
«Algoritmo para ofuscar técnica de ingeniería social» por Jimmy Olano está licenciado bajo Creative Commons Attribution-ShareAlike 4.0 International License.

Creative Commons Licence «Algoritmo para ofuscar técnica de ingeniería social» por Jimmy Olano está licenciado bajo Creative Commons Attribution-ShareAlike 4.0 International License. en una propuesta de algoritmo explicada en https://www.ks7000.net.ve/2016/01/10/ingenieria-social-en-informatica/.

Basandonos en nuestra experiencia, las contraseñas pudieran ser hasta de 11 caracteres, y a partir de 12 es que se considera que es larga dicha clave de seguridad. No necesariamente debe ser en el orden que nosotros indicamos arriba, aquello es una propuesta nemotécnica, no una cartilla para ejecutar a pie puntillas, ya que PARA NADA influye en el algoritmo de cifrado, cualquiera que ustedes escojan. En este artículo podrán leer unas cuantas recomendaciones para la creación de contraseñas, siempre teniendo en cuenta el uso de ingeniería social para intentar vulnerarlas. Y al menos nos queda el consuelo de que el consejo nemotécnico no aparece en la lista de las 25 primera contraseñas más tontas del mundo (en inglés). Actualizado el sábado 06 de febrero de 2016:

Aunque nuestra propuesta tiene cierta similaridad con el padding de las modernas funciones de «hash», la diferencia notable es que el usuario podrá agregar tanto texto (pulsaciones de teclas para ofuscar a los «mirones» del teclado) como desee, no es una norma en longitud; pueden leer más acerca del padding en este enlace web -en inglés y además con una explicación directa y sencilla sobre encriptamiento y «hashing» que suplementa nuestra entrada-

Algoritmo a utilizar.

Para poder utilizar dicho esquema que planteamos vamos introducir una «debilidad» en la seguridad de la base de datos. Dicha «debilidad» consiste en guardar, en una tabla aparte, la longitud de la contraseña ingresada antes de ser convertida a «hash» y almacenada. Si en algún momento hubiera acceso no autorizado a nuestra base de datos, el desencriptar los «hash» de contraseñas se facilitaría si sabemos de antemano la longitud fija. Además, tengamos en cuenta que hoy en día, por unos cuantos centavos de dólar estadounidense, se pueden probar 400 mil contraseñas por segundo en ataques de fuerza bruta con diccionarios predeterminados (recuerden aplicar «salt» para mitigar estos atques). En este enlace podreís leer más al respecto, pero con un fuerte sentido pesimista: «la unica contraseña segura es la que no puedes recordar«, en inglés.

Para prevenir -o al menos mitigar- esta futura debilidad, debemos olvidarnos de utilizar integridad referencial entre las dos tablas. Recomendamos que el idUsuario sea encriptado en «hash» y almacenado en otra tabla junto con el campo numérico largoContra, y recuperarlo justo en el momento que el usuario nos haya enviado su contraseña (la cual habrá viajado por encriptada y desencriptada por protocolo https por nuestro servidor).

El asunto sería fácil si estamos creando un sistema de autenticación totalmente nuevo. Lamentablemente ése NO es el mundo real, muy pocas veces se dan esos casos porque implica planificación y coordinación de muchas personas para llevar a cabo un proyecto, por pequeño que sea -o parezca-. La realidad es que «heredemos» dichos sistemas y, pues bueno, debemos adaptarlos a lo único que es constante: el cambio.

  1. Como dijimos, creamos nuestra tabla sin ninguna integridad referencial con dos campos: uno para almacenar el «hash» que representa al idetificador único y absoluto de usuario y otro campo numérico para guardar la longitud de la contraseña.
  2. Luego creamos un script -que utilizaremos una sola vez- para que recorra la tabla de usuarios, tome el identificador numérico de cada usuario, lo convierta en «hash» y lo guarde. El otro campo sería guardado con valor cero, sería una titánica tarea desencriptar los «hash» que representan a cada contraseña, sólamente para saber su longitud.
  3. Una vez hecho este proceso, procedemos a modificar el código para el registro de nuevos usuarios, para los que hayan olvidado sus contraseñas y/o para los que hayan caducado sus contraseñas.
  4. Acá usamos lo dicho en el punto N° 3 con el punto N° 1: al momento de generar el nuevo «hash» -de la nueva contraseña- tomamos nota de la longitud y la guardamos en la nueva tabla creada.
  5. Lo siguiente será modificar el algoritmo que valida a cada usuario: cuando reciba su identificador de usuario, aplicarle «hash» para buscarlo en la tabla recién creada, encontrarlo y leer la longitud de contraseña -«n» caracteres- y de la contraseña recibida vía protocolo https tomar sólamente los «n» primeros caracteres.
  6. El resto del proceso ya lo conoceís bien: a esos «n» primeros caracteres (leídos de izquierda a derecha, haced el correctivo si usáis un lenguaje como el árabe, por ejemplo) le generaís el «hash» habitual y comparadlo con el almacenado, si son iguales ¡BINGO! autenticación exitosa.
«Algoritmo para ofuscar técnica de ingeniería social» por Jimmy Olano está licenciado bajo Creative Commons Attribution-ShareAlike 4.0 International License.
«Algoritmo para ofuscar técnica de ingeniería social» por Jimmy Olano está licenciado bajo Creative Commons Attribution-ShareAlike 4.0 International License.

Bienvenidos al siglo XXI.

Acá volvemos a realizar una pausa para «explicar» la tendencia actual en esto de la autenticación de usuarios. Muy lejanos han quedado los días en que Richard Stalman «jaqueaba» las contraseñas de sus compañeros de trabajo para demostrarles que era una sensación de seguridad falsa, Y PENSAMOS QUE AÚN SIGUE TENIENDO RAZÓN, no hay sistema totalmente infalible.

Hoy, décadas después, existe un complejo de superioridad entre los geeks —aquellas personas que adoran y entienden cada novedad del mundo digital—, que creen tener habilidades que les dan poder especial sobre los demás. En el mundo ideal de Richard Stallman, poder comprender y arreglar una computadora no debía ser el don de unos cuantos.

Pero llegó el siglo XXI e implantó sus propias tácticas «anti-ingeniería social» de la cual hoy día nosotros aportamos nuestro granito de arena. El esquema, a grandes rasgos, es el siguiente:

    • Al principio (tiempos del joven Richard Stallman) «inventaron» el usar las contraseñas acompañadas de un nombre de usuario único en el sistema deseado. Luego con el advenimiento de la internet y sus sistemas de nombres de dominios únicos se pudo crear las direcciones de correo electrónico, las cuales heredan su unicidad. Aún hoy en día se acostumbra utilizar las direcciones de correo electrónico como nombres de usuario, por ser tanto dato como metadato, y ser únicas.
    • Precisamente las direcciones de correo electrónico sirvieron tanto para dar de alta a los usuarios, como para enviarles sus contraseñas, si se le olvidaba al usuario. Pero debido a la debilidad intrínseca del protocolo POP pues se ha relegado su uso.
    • Ahora se acostumbra utilizar la dirección de correo electrónico para enviar un enlace web con un identificador único a un servidor con protocolo https implementado y allí si crear la contraseña; esto garantiza que la dirección de correo electrónico sea válido y establece un canal de comunicación -inseguro- con la persona, pero canal al fin. También previene que realmente sea la persona titular de ese correo electrónico la que solicitó el registro de usuario, si no es así pues borra el mensaje y no ha pasado nada.
    • Como dijimos que el protoco de correo electrónico es inseguro -a menos que se utilice PGP -no todo el mundo lo utiliza- con solo saber la dirección de correo electrónico de una persona y utilizar la opción «olvidé mi contrseña» un atacante podrá desencadenar ese envio y esperará para interceptar -por algún método o manera- su llegada y asirse de ella.
    • Para evitar lo anterior pues no se envía la contraseña en sí misma, sino otro enlace con un identificador único que conlleva a que el usuario responda unas preguntas de seguridad -cuyas respuestas habrá suministrado al momento de registrarse-, tras lo cual, de resultar positivo, podrá conocer la contraseña en sí misma (ver siguiente punto). Aquí de nuevo interviene la ingeniería social: las respuestas NO DEBEN tener relación alguna con las preguntas previamente establecidas, he aquí un reportaje bien explicado sobre ese tema. (Actualizado el miércoles 27 de abril de 2016): en este enlace nos permite conocer cómo se llaman este tipo de «preguntas de seguridad» tal como las conocíamos SIN EMBARGO -y debido a nuestro idioma derivado del latín- el analista español de seguridad Sergio de los Santos (Cuenta Twitter @SSantosV) nos aclara que su nombre correcto es «CONTRASEÑAS COGNITIVAS». Os dejo el mensaje «tuit» correspondiente (el mensaje lo difunde Pablo González, persona distinta al autor):

  • Pero almacenar las contraseñas en un servidor se expone a que si alguien lograra entrar podría llevarse una copia de todas ellas. Por eso se encriptan mediante algoritmos de un solo sentido que estudiamos anteriormente, y como sabemos que lo que nosostros mismos encriptamos es prácticamente imposible de descifrar, pues es más fácil borrar el «hash» almacenado y que el usuario suministre una nueva contraseña.
  • Ya lo dijimos: es prácticamente imposible descifrar los «hash» pero con tiempo -y poder de hardware- eventualemente se logrará. Es por eso que se asume, se da por sentado, que dicho «hash» ya ha sido robado. Por ello, cada cierto tiempo, digamos mensualmente, se le solicita al usuario al ingresar que su «contraseña ha caducado» con lo cual se borra el «hash» y el usuario suministra una nueva contraseña -y aquí aprovechamos de guardar en una tabla aparte la longitud de caracteres de la misma- para generar un nuevo «hash». Cuando al final el o los atacantes que hayan robado los «hash» anteriores hayan logrado descifrarlos pues no coincidarán, ya serán diferentes por haber sido cambiados oportunamente.
  • ¿Recuerdan el canal de comunicación por medio de la dirección de correo electrónico del usuario? Pues en este punto, cuando registra una nueva contraseña, seria el momento adecuado de explicarle en un mensaje cómo funciona el nuevo algoritmo: introducir la contraseña en toda su extensión y a continuación pulsar las teclas que se deseen, simple y sencillo -por supuesto recordad establecer una longitud máxima al «input» del html-.
  • A las direcciones de correo electrónico se les ha mejorado su seguridad, por ejemplo Gmail solicita un número de teléfono móvil para enviarle un SMS con un código especial el cual debe ser ingresado al crear la cuenta de correo electrónico. Primero se garantiza que sea un ser humano quien hace la solicitud, segundo -pensando maquiavélicamente- la persona tiene cierto nivel de solvencia económica.
  • Basado en el punto anterior nació el Twitter el cual permite, primero por SMS -opción que ha caido en desuso- y segundo por aplicaciones instaladas en el teléfono móvil en sí, mantener informado al usuario. Esto inspiró a los bancos a realizar contratos con las operadoras telefónicas para integrar el envio de SMS a los clientes desde el mismo sistema informático del banco, ente quien conoce TODOS los datos de su cliente -y más valen que sean ciertos, sino, problemas legales-.
  • Así los bancos en el siglo XXI -e incluso otras grandes empresas- pueden alertar a sus clientes con un SMS cuando se realiza acceso a sus cuentas bancarias. Esto hace la ingeniería social mucho menos efectiva: un caso público y notorio reseñado por la prensa escrita da cuenta de un empleado bancario que accesó a la cuenta de una anciana para sustraerle dinero y llamó a la señora para indicarle que el banco estaba haciendo «unas pruebas«. La señora no se tragó el cuento y llegó a la agencia bancaria acompañada de la policía, hablaron con el gerente del banco y luego apresaron al ladrón tranquilamente sentado en el ordenador por donde ingresó a la cuenta bancaria.
  • Nosotros las empresas pequeñas nos conformamos con convencer a los usuarios para que nos agreguen en el Twitter por SMS y desarrollar una aplicación que automatice el envio de eventos (accesos, cambios de contraseñas, caducidad, etc.). Y si esto no fuera posible, al menos automatizamos el envio de mensajes por correo electrónico, que para nada nos debe dar vergüenza usarlo, que Youtube lo hace de esa manera.

De la teoría a la práctica.

De nada valdría hacer una propuesta si luego no es probada y comprobada. Probada será acá con un servidor que no maneja protocolo seguro (el futuro está cerca) pero al menos escribiremos de una manera muy corta y orientada a propósito didáctico, en lenguaje PHP, al algoritmo a implementar. Será nuestro primer -y pequeño- proyecto en Software Libre, lo comprimiremos y ofreceremos en este nuestro servidor, y será público en nuestra cuenta patrocinada por GitHub -gracias por el apoyo «thanks»-

Recomendación adicional.

Para crear un servidor virtual con datos de prueba podemos usar Vagrant con VirtualBox; como ese tema escapa a la longitud de este artículo solamente les dejamos un «tuit» con un enlace web sobre cómo crear esta máquina y luego utilizar git para crear un proyecto, está en inglés, bien resumido y claro:

También podeís utilizar libremente un «script» para crear estas máquinas virtuales (un proyecto totalmente separado del «tuit» arriba indicado) en el repositorio del señor Abr4xas en GitHub . Git es el protocolo y GitHub no es más que una página web que ofrece alojamiento por medio de este protocolo: los proyectos privados pagan y tienen otros beneficios adicionales a las cuentas gratuitas, cuyo código siempre debe ser público independientemente de la licencia escogida para el software desarrollado-. Para crear un servidor virtual con datos de prueba podemos usar Vagrant con VirtualBox; como ese tema escapa a la longitud de este artículo solamente les dejamos un «tuit» con un enlace web sobre cómo crear esta máquina y luego utilizar git para crear un proyecto, está en inglés, bien resumido y claro:

También haremos una funcion «log in» sin mayores pretensiones (dicho código fuente está publicado y amparado bajo esta licencia -en inglés: «This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL) «- ).

Si deseaís ir a lo complejo, leed este tutorial (fuera de este sitio web) para crear una muy bonita página web de entrada para validación de usuarios. Por supuesto, a mayor belleza, mayor trabajo para lograrlo. Nota: NO está desarrollado en un entorno de Software Libre, sin embargo el código fuente tiene cierto nivel de libertad, con propósitos didácticos nada más.

Casos de ingeniería social de la vida real.

(Actualizado el sábado 27 de agosto de 2016) Los siguientes son relatos fidedignos (dada la seriedad, trayectoria y conocimiento de los autores a los cuales seguimos por la red social Twitter) que ilustran el cómo la Ingeniaria Social es prácticamente un «arte bien cultivado», seguidamente les colocamos una pequeña descripción y enlace a los temas:

  • En una primera visita a un café, el autor Deepak Daswani (@dipudaswani) entra en la red inalámbrica del restaurante y «juega» con la rutina de los camareros con leves saltitos de sobresalto. En una segunda visita fortalecieron la red pero no deja de ser divertido el relato, HACEMOS NOTAR que esta vez se valió de un camarero nuevo que no había comenzado aún a trabajar en la primera visita. Hilarante humor «geek» para nosotros, gracias @ChemaAlonso por apoyar con el «reblog» de las historias.

Las mejores defensas

Actualizado el lunes 7 de enero de 2019

  1. No permitan favores de los demás a menos que ustedes mismos los hayan solicitado. Precisamente los favores no solicitados crean una predisposición de reciprocidad en posteriores peticiones con aviesas intenciones.
  2. Cualquier solicitud que salga de la rutina es sospechosa. Nunca se deben saltar procedimientos, por muy tontos que estos sean, además los nuevos procedimientos deben ser conocidos ampliamente por todos y el preguntarlos a cualquiera del personal de trabajo debe ser sin cortapisas, debe ser lo normal el preguntar para confirmar que está implementado.
  3. Recíproco a la regla anterior: que todos hagan lo mismo no quiere decir que esté implementado: debe estar por escrito primero, esto evita que dos o tres (o todos) hagan una conspiración. Todos deben dejar su compromiso por escrito.
  4. Un atacante siempre buscará hacer empatía con la víctima. Si es una mujer con cuerpo espectacular o un hombre con verbo o carisma, no debemos dejarnos influenciar por ello. Los actores y actrices regalan sonrisas por doquier. Aprendamos a analizar lo que está dentro de la caja y no el papel y el lazo que lo envuelve.
  5. El truco principal de la Wikipedia: todo está con referencias conocidas y reconocidas. El problema está cuando los atacantes se hacen pasar por estas autoridades, se disfrazan y tratan de engañarnos con esto. Siempre desconfiemos de los que se dicen expertos y autoridades hasta que hayamos verificado muy bien sus credenciales. El hecho que todos los den por autoridades no los acredita (recordar punto tres).
  6. No se dejen presionar por ultimátum alguno. Que algo se esté acabando no significa que debamos aceptarlo. Es solo un mecanismo de presión para que cedamos a las peticiones insanas.

Básicamente todo lo anterior se reduce a verificación de identidad y verificación de deberes  y derechos de la persona que haya aprobado el primer paso, pero recuerden siempre «todo por escrito», tipo Sheldon Cooper.

Fuentes consultadas.

En idioma castellano:

 
Download PDF